[zeromq-dev] blocking zmq_close?

[Whitney Jackson]

> How about removing the socket's fd from the eventloop's monitoring at the time
> of close? It would be surprising if you can add an fd but not remove it...

Yep.  The propriety event loop does provide a mechanism for removing
fds as well as adding them. I use that and can verify using strace
that the event loop no longer includes my fd in it's select calls
afterwards.  Sadly, it still blows up as soon as I close the socket if
I don't zmq_term or sleep.  I'm guessing somewhere in the code I can't
see the fd is being touched in a way that doesn't show up in strace.

I could go the route of filing a bug with the commercial / closed
source event loop people but am guessing I won't have much luck there.
 If it's possible to work around this by just not giving control back
to the event loop until the socket is fully closed that would be
ideal.

On Wed, Jul 4, 2012 at 8:52 PM, Justin Karneges <justin at affinix.com> wrote:
> On Wednesday, July 04, 2012 05:57:36 PM Whitney Jackson wrote:
>> Hi,
>>
>> I'm using the ZMQ_FD getsockopt feature to integrate ZeroMQ into an
>> event loop that I don't control and don't have the source code for.
>> This works quite well except when I want to close a ZeroMQ socket.
>> Since zmq_close is non-blocking, control gets returned to the event
>> loop before the socket is fully shutdown causing this error:
>>
>> Bad file descriptor (epoll.cpp:69)
>>
>> gdb on the core file shows
>>
>> #0  0xf77bf430 in __kernel_vsyscall ()
>> #1  0x45d7395f in raise () from /lib/libc.so.6
>> #2  0x45d752b3 in abort () from /lib/libc.so.6
>> #3  0xf36f719c in zmq::zmq_abort (errmsg_=0x45eaf393 "Bad file
>> descriptor") at err.cpp:76
>> #4  0xf36f5f0a in zmq::epoll_t::add_fd (this=0x9029a10, fd_=14,
>> events_=0x902a2b0) at epoll.cpp:69
>> #5  0xf370c3d7 in zmq::socket_base_t::start_reaping (this=0x902a210,
>> poller_=0x9029a10) at socket_base.cpp:717
>> #6  0xf3705a87 in zmq::reaper_t::process_reap (this=0x90287e0,
>> socket_=0x902a210) at reaper.cpp:101
>> #7  0xf36fbfd4 in zmq::object_t::process_command (this=0x90287e0,
>> cmd_=...) at object.cpp:120
>> #8  0xf370591f in zmq::reaper_t::in_event (this=0x90287e0) at reaper.cpp:72
>> #9  0xf36f64f7 in zmq::epoll_t::loop (this=0x9029a10) at epoll.cpp:161
>> #10 0xf36f65c5 in zmq::epoll_t::worker_routine (arg_=0x9029a10) at
>> epoll.cpp:174 #11 0xf3710792 in thread_routine (arg_=0x9029a54) at
>> thread.cpp:75 #12 0xf7749adf in start_thread () from /lib/libpthread.so.0
>> #13 0x45e3655e in clone () from /lib/libc.so.6
>>
>> I can prevent the error by doing a zmq_term on the context or just
>> sleeping before returning control to the event loop but obviously
>> these solutions aren't optimal.
>>
>> Is there some way to block until zmq_close is really done?
>
> How about removing the socket's fd from the eventloop's monitoring at the time
> of close? It would be surprising if you can add an fd but not remove it...
>
> Justin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev