On Fri, Jan 25, 2008 at 07:43:47AM -0300, Gustavo Sverzut Barbieri wrote: > 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. >
Thanks for your comments and suggestions. I thinks I'll go with the pipe solution as I think there are too many unknowns with pselect: will it work if we build againts uclibc, newlib or klibc? or build on BSD or Solaris systems etc? Regards -- Lars Munch ------------------------------------------------------------------------- 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
