[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #4457 [Tor Client]: Assertion at startup on Windows 7 when socketpair fails
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs