On 02/02/2012 01:02 PM, Derek Zhou wrote:
Although it does a second poll after the sig handler setup trying to catch
this possibility, the data could still come in after the second poll but
before the _gst_sync_wait. The sig handler will trigger but it does not
prevent the process going to sleep.
From the look of it the problem is not limited to pipes, the same could
happen to sockets as well.
Possible fixes:
* block SIGIO until the process is really asleep in an atomic operation.
However I don't know how.
It must be more subtle than that.
The SIGIO will not be processed immediately; it will be processed before
executing the next bytecode. This should close the race window with the
update of the list. In fact, the second poll could be removed, I think.
Paolo
_______________________________________________
help-smalltalk mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
