On Thu, 24 Jan 2008 12:03:26 +0100 [EMAIL PROTECTED] (Lars Munch) babbled: > Hi > > While working on suspend/resume on my embedded system I ran into to the > race problem between select and signals. See this link for a description > of the problem: > > http://www.xs4all.nl/~evbergen/unix-signals.html > > The problem is that the following code in ecore_main_select is not an > atomic operation and could end up in select waiting forever even though > there is a signal to be served and put in the event queue: > > if (_ecore_signal_count_get()) return -1; > ret = select(max_fd + 1, &rfds, &wfds, &exfds, t); > > My proposed solution (see attached patch) is something similar to that > described in above link, namely to create a pipe to flag a signal > arrival to select. NOTE: the attached patch currently only handles > sigusr1 and sigusr2 and has almost no error checking. > > As far as I can tell, the attached patch still have a race around > sig_count and sigXXX_count. I thought about adding the signal number to > the signal pipe to avoid this race, but that solution could result in > pipe buffer overflow and then signals would get lost. > > Before I continue working on this patch, I really like your comments and > suggestions.
oh yeah. very good point. and yes - a race condition - a very small one, but there nevertheless. now nathan's solution - sigmask and pselect. that could work. problem is - pselect. how will that affect us. not sure. never touched it. the pipe/fd solution should work. we dont use it for delivery of signals ONLY to wake select up. just a dumb fd we write a single byte to in the sig handler. that means select should go in and then instantly come out if there was a signal. we can have another global flags of "sig_pipe_write". i.e sig_pipe_write++; if (_ecore_signal_count_get()) return -1; et = select(max_fd + 1, &rfds, &wfds, &exfds, t); sig_pipe_write--; and in signal handler add: ... unsigned char dummy_buf = 1; if (sig_pipe_write > 0) write(signal_pipe, &dummy_buf, 1); ... this means that whenever in select we also get a write on any signals that will cause select to wake up when it is next called. we will get extra select() wakeups tho (and wakeups for just the reason that the pipe buffer has data). of course i am assuming non-blocking writes to this signal pipe fd, so if they fail - thats ok. the fact the buffer has data is enough to wake select up and avoid the "long term sleep" bug. next time select returns the signal stuff will be fixed up and handled- it just means we get a possible delay (until something else wakes select up). using the pipe we force it to wake up. 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? -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
