On Jan 24, 2008 11:42 PM, Nathan Ingersoll <[EMAIL PROTECTED]> wrote:
> On Jan 24, 2008 7:18 PM, The Rasterman Carsten Haitzler
> <[EMAIL PROTECTED]> wrote:
> >
> > now i think this is a bit more generic a solution - but it adds overhead. so
> > what about the pselect() method? anyone got input on that?
>
> Basically, pselect() is designed for exactly this situation. You block
> all of the signals you're going to handle during init or some other
> very early point, then you pass a mask of the signals you're going to
> unblock to pselect(). At this point, pselect() will atomically unblock
> the specified signals and call select() with the specified fd's, it
> also re-instates the original signal blocks after select() returns.
> Since this sequence is atomic, it prevents the race condition we
> currently have.
>
> Now the problem, this is a good solution on BSD and Solaris, but
> unfortunately Linux only fakes support for pselect() (unless this was
> fixed recently). On Linux pselect() is actually a wrapper exactly
> around the sequence sigprocmask(), select() sigprocmask(). So we still
> end up with a race condition between the first sigprocmask() call and
> the select() call.
man page says:
BUGS:
Since version 2.1, glibc has provided an emulation of pselect()
that is implemented using sigprocmask(2) and select().
This implementation remains vulnerable to the very race
condition that pselect() was designed to prevent. On systems
that lack pselect() reliable (and more portable) signal
trapping can be achieved using the self-pipe trick (where a
signal handler writes a byte to a pipe whose other end is
monitored by select() in the main program.)
however a bit earlier it says Linux has pselect(), and at least 2.6.23
implements it... so maybe this wrapper is just used as a fallback?
--
Gustavo Sverzut Barbieri
--------------------------------------
Jabber: [EMAIL PROTECTED]
MSN: [EMAIL PROTECTED]
ICQ#: 17249123
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
