Re: [Python-Dev] Polling with Pending Calls?

This patch may interest you: http://www.python.org/sf/1564547 Not sure it completely solves your case, but it's at least close to your problem. On 12/4/06, Tony Nelson <tonynelson@georgeanelson.com> wrote:
I think I have a need to handle *nix signals through polling in a library. It looks like chaining Pending Calls is almost the way to do it, but I see that doing so would make the interpreter edgy.
The RPM library takes (steals) the signal handling away from its client application. It has good reason to be so paranoid, but it breaks the handling keyboard interrupts, especially if rpmlib is used in the normal way: opened at the beginning, various things are done by the app, closed at the end. If there is an extended period in the middle where no calls are made to rpmlib (say, in yum during the downloading of packages or package headers), then responst to a keyboard interrupt can be delayed for /minutes/! Yum is presently doing something awful to work around that issue.
It is possible to poll rpmlib to find if there is a pending keyboard interrupt. Client applications could have such polls sprinkled throughout them. I think getting yum, for example, to do that might be politically difficult. I'm hoping to propose a patch to rpmlib's Python bindings to do the polling automagically.
Looking at Python's normal signal handling, I see that Py_AddPendingCall() and Py_MakePendingCalls(), and PyEvel_EvalFrameEx()'s ticker check are how signals and other async events are done. I could imagine making rpmlib's Python bindings add a Pending Call when the library is loaded (or some such), and that Pending Call would make a quick check of rpmlib's caught signals flags and then call Py_AddPendingCall() on itself. It appears that this would work, and is almost the expected thing to do, but unfortunately it would cause the ticker check to think that Py_MakePendingCalls() had failed and needed to be called again ASAP, which would drastically slow down the interpreter.
Is there a right way to get the Python interpreter to poll something, or should I look for another approach?
[I hope this message doesn't spend too many days in the grey list limbo.] -- ____________________________________________________________________ TonyN.:' The Great Writ <mailto:tonynelson@georgeanelson.com> ' is no more. <http://www.georgeanelson.com/> _______________________________________________ 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/gjcarneiro%40gmail.com
-- Gustavo J. A. M. Carneiro "The universe is always one step beyond logic."

At 6:07 PM +0000 12/4/06, Gustavo Carneiro wrote:
This patch may interest you: <http://www.python.org/sf/1564547>http://www.python.org/sf/1564547
Not sure it completely solves your case, but it's at least close to your problem.
I don't think that patch is useful in this case. This case is not stuck in some extension module's poll() call. The signal handler is not Python's nor is it under my control (so no chance that it would look at some new pipe), though the rpmlib Python bindings can look at the state bits it sets. The Python interpreter is running full-bore when the secret rpmlib SIGINT state is needed. I think the patch is for the exact /opposite/ of my problem. -- ____________________________________________________________________ TonyN.:' The Great Writ <mailto:tonynelson@georgeanelson.com> ' is no more. <http://www.georgeanelson.com/>
participants (2)
-
Gustavo Carneiro
-
Tony Nelson