[zeromq-dev] odd zmqstream.py behavior

[MinRK]

On Wed, Oct 6, 2010 at 08:33, Steve Huffman <steve at hipmunk.com> wrote:

> Brian,
>>
>> I added to my zmqstream branch, which updates the zmqstream object to have
>> the rest of the socket interface (now everything except recv*).  It also no
>> longer closes the socket on an error in a callback, it merely unregisters
>> the callback.
>>
>
> While not closing the socket on an error prevents sockets from silently
> dying, it also potentially leaves file descriptors hanging around. That
> said, the sockets silently closing has bitten me a couple of times, both in
> zmqstream and in Tornado's iostream. I feel like the correct solution would
> be to print the exception so the developer can at least see an explanation
> and possibly wrap the callback call in a NullContext. Either way, I think
> it's important to match the logic of Tornado when possible since Tornado has
> a lot more production users, so things are the way they are for a reason.
> I'm also chatting with Ben from Tornado, who added the StackContext stuff in
> the first place, to see if this makes sense.
>

I actually hadn't edited _run_callback() at all from the original tornado
iostream, nor close(), so the handling should be the same as theirs in
master. I changed it only to resolve this issue.  I understand that the
issue here is that zmq_close() is blocking, which shouldn't happen, and I
can't make it happen. It sounds to me like the problem is *not* in
zmqstream.

In Tornado, if a user callback raises an exception, then the fd gets closed
and put away.  Now, we have sending and recving to consider, so I'm not sure
that an error on a user's recv callback should mean we can't send via that
socket anymore, but that's the decision that Tornado made, and we can
continue to follow it, as we do in current master.


>
>
>> Steve,
>>
>> I can't actually reproduce the issue at the head of this topic with
>> master, though.  I see the loop properly logging the error and marching
>> right along, having closed and detached the socket. Can you post a sample of
>> where it hangs, and check against my zmqstream branch on github (
>> http://github.com/minrk/pyzmq/tree/zmqstream) to see if that behaves any
>> better?
>>
>> I'm using zmq 2.0.9.
>>
>
> Yep, will let you know.
>
>
>
>>
>> -MinRK
>>
>> On Mon, Oct 4, 2010 at 20:20, Brian Granger <ellisonbg at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Min and I looked at this today and this is a bug in pyzmq.  When a
>>> callback in the eventloop raises, we are currently closing the socket,
>>> which we should not do.  We are still figuring out the error handling
>>> symantics, but we should have a fix in place soon in pyzmq master.
>>>
>>> Cheers,
>>>
>>> Brian
>>>
>>> On Fri, Oct 1, 2010 at 7:08 PM, Pieter Hintjens <ph at imatix.com> wrote:
>>> > On Sat, Oct 2, 2010 at 3:58 AM, Steve Huffman <steve at hipmunk.com>
>>> wrote:
>>> >
>>> >> I don't think so. I'll try the new version, but what the behavior I'm
>>> seeing
>>> >> is zmq_close() doesn't return when an exception is thrown in the
>>> callback.
>>> >
>>> > I didn't read your email properly, sorry... zmq_close() should not
>>> block.
>>> >
>>> > If you can follow what zmqstream is doing, and get a straight pyzmq
>>> > example that has the same behavior, that'll make it easier to debug.
>>> >
>>> > -Pieter
>>> > _______________________________________________
>>> > zeromq-dev mailing list
>>> > zeromq-dev at lists.zeromq.org
>>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> >
>>>
>>>
>>>
>>> --
>>> Brian E. Granger, Ph.D.
>>> Assistant Professor of Physics
>>> Cal Poly State University, San Luis Obispo
>>> bgranger at calpoly.edu
>>> ellisonbg at gmail.com
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101006/fdc1f072/attachment.htm>