[zeromq-dev] Stopping zmq_device

[Martin Sustrik]

Jarred, Brian,

>> 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?
> 
> For the Ruby extension, it is also very desirable to have the ability to 
> interrupt a blocking call on a socket.  Ruby 1.9's API for blocking 
> operations includes a callback that is invoked when the thread is to be 
> interrupted/terminated (by another Ruby thread, or by Ctrl-C, or a 
> signal handler...), but currently I can't implement this callback 
> without turning all 0MQ calls into zmq_poll() calls and using my own 
> notifier fd for each socket (ugly!)
> 
> So, it would be nice to have something like zmq_interrupt(socket) or 
> zmq_abort(socket) that would cause any outstanding blocking calls on 
> that socket to be resumed with errno = EINTR.

The use cases make sense. However, at this point we are treading into 
the territory of signals and signal handling which is pretty complex and 
hard to get right (see the mess that POSIX signals are).

We have to have a clear idea of what exactly we want, how does it 
interact with other related functionality (say OS signals), how can it 
be exposed via a clean POSIX API etc.

Martin