[zeromq-dev] zmq_poll

Martin Sustrik sustrik at 250bpm.com
Mon May 24 08:20:06 CEST 2010

Serge Aleynikov wrote:
> Martin,
> I sited SCTP merely as an example of separation of an association from 
> the transport layer socket, which makes it possible to poll for SCTP 
> events on a single fd and dispatch the messages to application-level 
> queues handling association-specific content.  It would be fine to have 
> different OS threads working on those queues interchangeably.
> Conceptually the 0MQ socket can be perceived as an SCTP association; 0MQ 
> socket subscription is like an SCTP stream; and 0MQ app_thread's 
> signaling fd is like SCTP one-to-many socket.

Ok, I got it.

> Though after my initial introduction to 0MQ I believed it would be a 
> good idea to have a BSD file descriptor associated with each 0MQ socket, 
> after giving it more thought, it seems unnecessary as it would associate 
> a 0MQ socket with a wrong OSI layer.  The multiplexing problem needed to 
> be solved by the library is how to route messages between N logical 
> subscriptions and M transport connections within a single process (as I 
> understand the actual 0MQ implementation is slightly different as M 
> transport connections are never shared between 0MQ sockets).  A 0MQ 
> socket is a "user-level queue" associated with one or more 
> subscriptions.  A dispatching engine running in some OS thread would be 
> triggered when there's an I/O activity and it would read and replicate 
> incoming messages to application-level 0MQ queues based on details of 
> the subscription matrix.  In cases when application-level code needs 
> more than 1 0MQ socket, instead of associating them with a file 
> descriptor for providing an application with ability to poll on multiple 
> sockets, it could be avoided by registering a notification callback 
> triggered when there's a message to read.  This way no enforcement of 
> any threading model on the application layer is needed.  0MQ sockets 
> would be merely light-weight queues for reading/writing messages from 
> any OS thread context and the user could control how application-level 
> notification is handled through implementing that functionality in the 
> callback.

As for the callbacks, there are many reasons why not to use them in 
libzmq. I've enumerated them in an email to the mailing list recently.

However, it definitely makes sense to create a library on top of 0MQ 
that would allow user to register callbacks, manage the worker threads 
to invoke callbacks etc.


More information about the zeromq-dev mailing list