On Jan 29, 2008 9:14 AM, Lars Munch <[EMAIL PROTECTED]> wrote: > > 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.
Ah, I understand your question now. When we receive the signals now, don't we defer the delivery of those signals anyways? I lean towards simplifying the code if we can, since signals are asynchronous and shouldn't be counted on to be delivered in a timely manner, just in-order. > > > > 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. Oh, even better. I would probably just add a check to the configure.in for pselect, and then ifdef to select without the signal mask. ------------------------------------------------------------------------- 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
