Verify destructor order is correct

[erickt]

Verify destructor order is correct

[erickt]

This is the normal ZMQ behavior, unless I'm missing something.

ZMQ supports two modes for shutting down the context. The first and default is that zmq_ctx_destroy will block until all the sockets are shut down across all of the threads. This is so ZMQ can guarantee all the messages have hit the underlying OS sockets. However this mechanism can cause a deadlock, because a ZMQ_REQ could be stuck waiting for a reply that may never happen. To avoid this scenario, you can set the socket option ZMQ_LINGER on the socket, as in socket.set_linger(100). This will give that ZMQ socket 100ms to finish it's IO before ZMQ will kill the OS socket and destroy the context.

I'm going to close this issue, but please feel free to reopen if I misinterpreted your problem.

[emberian]

I can't reopen, but I think it should. I know this is how zmq works, but I think the wrapper is potentially incorrect. If you create sockets, and if their destructors don't get called before the context's destructor does, there will be an accidental hang.

[emberian]

Note that it's not anything the user can control, it's the order the compiler decides to call constructors in. I imagine it'd do it in reverse creation order, but it needs to be verified.

[erickt]

I get what you are saying, but is there any way to express this destructor dependency between contexts and sockets? Someone could always write:

fn bad() -> zmq::Socket {
  Let ctx = zmq::Context::new().unwrap();
  ctx.socket(zmq::ZMQ_REQ)
}

I don't think we can prevent that at compile time. Especially as we want to support moving sockets between threads.

The only other option I can think of is to just remove the destructors and potentially leak sockets/contexts. I'm not crazy about that idea though.

[emberian]

Hrm, tricky. Don't think there's a nice way to do this "properly" :\