[zeromq-dev] Stopping zmq_device

[Jarred Ward]

>
> As for the problem of exiting the devices what about this dumb patch:
>
>
> http://github.com/sustrik/zeromq2/commit/11891ddd5577321a351a1850d28478e97f4b9162
>
> What it does is that when context is terminated (zmq_term) all the
> associated devices exit with ETERM error.
>
> The patch is in my private repo only so far but it can be merged into
> the trunk easily.
>

Simple and gets the job done. I think this should be merged into trunk.


> Yes. This can be done, but killing a socket from a different thread is
> kind of ugly. Any use cases for that aside of stopping the devices?


A couple of use cases I can think of:

*Breaking a blocking socket recv without a context term. Ie stopping a
receiving server socket. Right now if we have 5 threads receiving on a
single context and we need to shutdown just 1 socket we're forced to context
term and kill all 5 just to stop that single thread (unless you're polling).
I realize you could go 1:1 with context:socket or actually interrupt the
thread the socket is running on (which may corrupt something?), but those
just don't seem right.

*Updating state on a blocking socket. The nice thing about an interrupt
would be that the socket would remain usable afterward so you could
interrupt the socket, signal some state change in the socket (ie: add
another sub topic or downstream socket) and then start receiving again.

I think that forcibly releasing a blocking recv on a single thread from
another thread with a socket interrupt makes the most sense. I think the
recv should return an EIR (interrupt request) signalling that it was
interrupted and the socket should remain usable afterward.

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100709/99640847/attachment.htm>