[Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).

[Gustavo Carneiro]

On 07/12/2007, Sean Reifschneider <jafo-python-dev at tummy.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20071207/3eafef5c/attachment.htm