[Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).
gjcarneiro at gmail.com
Fri Dec 7 15:48:51 CET 2007
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:
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...
More information about the Python-Dev