Mon Feb 1 21:24:17 CET 2010
Although Python signal handlers are called asynchronously as far as
the Python user is concerned, they can only occur between the =93atomic=94
instructions of the Python interpreter. This means that signals
arriving during long calculations implemented purely in C (such as
regular expression matches on large bodies of text) may be delayed for
an arbitrary amount of time.
To test this I did the following:
s.recv() # this block for a long time
While this was blocking, I did ctrl-C, and then later sent a message
to this socket to it would become unblocked.
At that point, Python raised KeyboardError (the default sig handler
raises that for ctrl-C). This simple experiment show that:
1. Python's signal handler is still installed and working properly.
2. When blocking on zmq_recv, the Python interpreter is "not in
control." (the 0MQ C++ code is running) and thus can't respond to the
signal until it gets control.
Thus, I think the only way of resolving this if 0MQ is making out
signals in the IO threads. Thoughts?
On Tue, Mar 9, 2010 at 10:59 AM, Chris Wong <chris at chriswongstudio.com> wro=
>>> When would you want to unblock a blocked zmq_recv()? The only time I ca=
>>> think of doing that legitimately is when the entire application/compone=
>>> is going away, in which case we want to change the behaviour of zmq_ter=
>>> as discussed in my other email.
>> I agree that most of the time, you would be exiting the application.
>> But, you might want to trigger
>> clean up actions of various sorts, before exiting.
> That's what the Ruby's signal handler does AFAIK (not entirely sure thoug=
h). It has a lot of clean-up stuff to do. =A0I don't even want to get into =
the details because it's hurting my head just to think about it. ;-)
> One of the thing it does (for sure) is to call the internal "finalize" fu=
nction on each object in the GC system to do resource cleanup. =A0Like Java=
, I don't think it's guaranteed, but I observe that it's currently doing it=
>> Brian E. Granger, Ph.D.
>> Assistant Professor of Physics
>> Cal Poly State University, San Luis Obispo
>> bgranger at calpoly.edu
>> ellisonbg at gmail.com
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com
More information about the zeromq-dev