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? -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
