On Jan 25, 2008 12:40 AM, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > On Fri, 25 Jan 2008 00:11:41 -0300 "Gustavo Sverzut Barbieri" > <[EMAIL PROTECTED]> babbled: > > > > 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? > > that is the question - is it implemented kernel-wise widely enough to use it? > or do we just stick to the old-fashioned self-pipe trick?
I have not audited the Linux or GlibC code to check if that's the case (well implemented), but I truly believe that we can rely on this call for newer (> 2.6) kernels. -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
