No subject

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?

Cheers,

Brian
On Tue, Mar 9, 2010 at 10:59 AM, Chris Wong <chris at chriswongstudio.com> wro=
te:
>>> When would you want to unblock a blocked zmq_recv()? The only time I ca=
n
>>> think of doing that legitimately is when the entire application/compone=
nt
>>> is going away, in which case we want to change the behaviour of zmq_ter=
m()
>>> 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=
 consistently.
>
> Chris
>
>> Brian
>>
>>
>> --
>> Brian E. Granger, Ph.D.
>> Assistant Professor of Physics
>> Cal Poly State University, San Luis Obispo
>> bgranger at calpoly.edu
>> ellisonbg at gmail.com
>
>



--=20
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com