On 07/12/2007, Sean Reifschneider <[EMAIL PROTECTED]> wrote: > > On Thu, Dec 06, 2007 at 10:55:12PM -0700, Adam Olsen wrote: > >That's pretty much what issue1564547 does. I think there's two marks > > Good point, I hadn't seen that before. > > >* Using poll and fd's is pretty platform specific for what should be a > >general-purpose API > > I would say that this is an optimization that helps a specific set of > platforms, including one that I think we really care about, the OLPC which > needs it for decreased battery use. It doesn't cause breakage of > other platforms, it just may not help them.
Not only that, but current python signal handling is not theorethically async safe; there are race conditions in the Py_AddPendingCalls API, and it just happens to work most of the time. BTW, the problem is described here: http://mail.python.org/pipermail/python-dev/2006-September/068569.html Think of even python select.poll and multiple threads. If you have dozens of threads, each blocked in some system call, when a signal arrives it will interrupt one of the system calls, causing it to return EINTR, and then python checks for signals. Now imagine all the non-main threads are not created by python; then one of the threads that wakes up could very well be non-python one, and so python will never realize a signal was delivered. The solution of blocking signals in all but the python thread(s) is not feasible as we cannot control all threads that are created, some are created by C libraries... -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
