[tor-bugs] #4457 [Tor Client]: Assertion at startup on Windows 7 when socketpair fails

[Tor Bug Tracker & Wiki]

#4457: Assertion at startup on Windows 7 when socketpair fails
------------------------+---------------------------------------------------
 Reporter:  Vigdis      |          Owner:                    
     Type:  defect      |         Status:  new               
 Priority:  major       |      Milestone:  Tor: 0.2.2.x-final
Component:  Tor Client  |        Version:  Tor: 0.2.2.34     
 Keywords:              |         Parent:                    
   Points:              |   Actualpoints:                    
------------------------+---------------------------------------------------

Comment(by nickm):

 Hm.  Several possibilities here, not all conflicting.

  * Set event_base_flag_nolock on newly constructed bases for situations
 where we know we don't need to access a base from multiple threads.  Right
 now that's "every situation", but that won't be the case forever (maybe).

  * Or maybe start with trying to create it regularly, and retry with
 nolock if that fails.

  * Detect failures from event_base_new_with_config.

  * event_base_new_with_config() should log in this case.

  * Libevent should decline to "enable threading" on a base in the case
 when no threading callbacks have been registered with Libevent.

 Information:

  * With nearly all event backends,  the only way to make the poll function
 wake up is to make one of the sockets become active.  On Linux, you do
 this with a eventfd() ; everyplace else, you use a socketpair.

  * Windows doesn't have real socketpairs, so you've got to fake them by
 connecting to localhost... which some firewalls get annoyed by.

  * Libevent needs to be able to wake up the poll function to handle inter-
 thread communication and to implement signals (on non-kqueue, non-signalfd
 backends).  Tor uses this ability for cpuworkers and for signals.

  * The alternative methods of waking up a poll function are "Use a
 different poll function" (not 100% possible on Windows with current
 libevents, though we're moving in that direction), "Don't let your poll
 functions wait longer than some small amount; accept that amount of time
 as acceptable latency in inter-thread communication" (ugly, cpu-
 intensive), and "and then a miracle occurs".

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4457#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online