On Tue, Jan 29, 2008 at 08:48:42AM -0600, Nathan Ingersoll wrote: > On Jan 29, 2008 8:03 AM, Lars Munch <[EMAIL PROTECTED]> wrote: > > On Sat, Jan 26, 2008 at 01:16:24PM -0600, Nathan Ingersoll wrote: > > > I checked the man page for Mac OS X as well. Looks like pselect() > > > comes from FreeBSD in that case. > > > > Ok, you got me convinced. Attached is a pselect version of the race fix. > > > > Two questions remain: > > > > 1. Do we want to keep all signals blocked except in the pselect call or > > do we want to unblock signals after the pselect call? > > You don't want to maintain the block through the pselect call because > signals should cause it to return before it's expiration time is > reached, so I would block except when inside pselect.
Ok, I might have asked the question wrongly. My current patch already calls pselect with an empty set of signals, so signals will only be handled when pselect is called. As an alternative we could do: _ecore_main_select() 1. block signals 2. check signals 3. call pselect with an empty set 4. unblock signals that way we can receive/handle signals at (almost) any time (like we do now). The first method has the benefit that we always handle signals at the same place and that we can remove a lot of the signal checking stuff from the main loop. The second method has the benefit that the signal handler is called almost immediately. > > 2. pselect breaks the win32 port. what is the best way to handle this? > > implement our own pselect for win32 using select or use "#ifdef's" ? > > I believe Vincent is working on a library of win32 work-arounds, maybe > he can propose an alternative call for that case. If not, then the > pipe method described previously may need to be implemented for win32, > or we live with a race condition by emulating pselect like glibc does. Signals do not exists on windows, so there is no race. The question is only if we could use #ifdefs or make a pselect windows function without the signal stuff using select. Thanks for your fast feedback 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
