Gustavo Carneiro wrote: > OK, let's review what we know about current python, signals, and threads: > > 1. Python launches threads without touching sigprocmask; > 2. Python installs signal handlers for all signals; > 3. Signals can be delivered to any thread, let's assume (because > of point #1 and not others not mentioned) that we have no control over > which threads receive which signals, might as well be random for all > we know; > 4. Python signal handlers do almost nothing: just sets a flag, > and calls Py_AddPendingCall, to postpone the job of handling a signal > until a "safer" time. > 5. The function Py_MakePendingCalls() should eventually get > called at a "safer" time by user or python code. > 6. It follows that until Py_MakePendingCalls() is called, the > signal will not be handled at all! > > Now, back to explaining the problem. > > 1. In PyGTK we have a gobject.MainLoop.run() method, which blocks > essentially forever in a poll() system call, and only wakes if/when it > has to process timeout or IO event; > 2. When we only have one thread, we can guarantee that e.g. > SIGINT will always be caught by the thread running the > g_main_loop_run(), so we know poll() will be interrupted and a EINTR > will be generated, giving us control temporarily back to check for > python signals; > 3. When we have multiple thread, we cannot make this assumption, > so instead we install a timeout to periodically check for signals. > > We want to get rid of timeouts. Now my idea: add a Python API to say: > "dear Python, please call me when you start having pending calls, > even if from a signal handler context, ok?"
What can be safely done from a signal handler context is *very* limited. Calling back arbitrary Python code is certainly not safe. Reliable asynchronous interruption of arbitrary code is a difficult problem, but POSIX and POSIX implementations botch it particularly badly. I don't know how to implement what you want here, but I'd endorse the comments of Nick Maclaren and Antony Baxter against making precipitate changes. -- David Hopwood <[EMAIL PROTECTED]> _______________________________________________ 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