I checked the man page for Mac OS X as well. Looks like pselect() comes from FreeBSD in that case.
On Jan 26, 2008 9:09 AM, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: > > 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 > ------------------------------------------------------------------------- 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
