On Jan 26, 2008 6:13 AM, Lars Munch <[EMAIL PROTECTED]> wrote: > > 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?
Solaris was already said to work by Nathan, Linux kernel implements it, so uclibc and newlibc or klibc should support it, if not let's bug report and have it done ASAP. BSD I'm not sure, any users out there to reply about this (checking the man page should be enough)? -- 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
