[zeromq-dev] zmq_poll

Serge Aleynikov serge at aleynikov.org
Tue May 11 20:29:05 CEST 2010


 > Several points:
 >
 > 1. In the long run, 0MQ sockets should be turned into standard POSIX
 > sockets so that there would be no need for zmq_poll anymore.

Yes, this would make a lot of sense!

 > 3. The API you propose doesn't match how things work inside 0MQ.
 > There's only one file descriptor involved etc. Let me propose
 > alternative interface:
 >    //  Returns file descriptor you can poll on (POLLIN) to find
 >    //  out whether _something_ is to happen within specified
 >    //  0MQ context. When the fd is signaled, zmq_process should
 >    //  be called to do the outstanding work. You should never
 >    //  read from the file descriptor yourself.
 >    int zmq_wait_fd (void *context_);

I might be missing something but wouldn't it have to be:

     int zmq_wait_fd (void *socket_);
                            ^^^^^^^
i.e. isn't there an fd per socket (0MQ's or other)?

Also I saw the app_thread->process_commands() call inside zmq_poll to 
handle 0MQ messages, would we also need to register that signaling fd 
with an external loop as well?

 >    //  Process whatever outstanding work within 0MQ context.
 >    int zmq_process (void *context_);

I am a little unclear with this call as to how would the external loop 
set the context->revents to indicate POLLIN/POLLOUT activity, so that 
zmq_process would be able to know if this is a read/write activity. 
Wouldn't it need to be:

      int zmq_process (void *context_, int events);

      where events is a bitmask of POLLIN/POLLOUT

 >    //  Returns IN event, OUT event or both for the particular
 >    //  0MQ socket.
 >    int zmq_events (void *socket_);

I think I am mis-reading your suggested API, as I don't see the purpose 
of this one?

 > Would that work with Erlang VM?

Erlang has a function used to provide the VM with events to check for on 
a given fd:

      driver_select(..., int event, int mode, int on)
                              ^          ^         ^
                              |          |         |
                             fd    POLLIN/OUT   Turn on/off

And the VM calls one of two callbacks when there's activity
detected:

      void (*ready_input)(..., int event);
      void (*ready_output)(..., int event);

Actually this type of registration model is pretty common, and I saw it 
in several event loop libraries.

Serge

On 5/11/2010 10:23 AM, Serge Aleynikov wrote:
> Hi,
>
> The current design of zmq_poll(3) call assumes the "ownership" of a the
> event objects such that it'll make the underlying poll call on the
> number of event objects (i.e. file descriptors or zmq sockets) and block
> for a specified timeout.
>
> When integrating this library with other libraries (such as Erlang VM),
> they may have their own event loop and facility to add/remove file
> descriptors along with providing a callback indicating that there's
> activity on given file descriptors.
>
> I'd like to see if the following requirement sounds reasonable.
>
> Objective
> ---------
> Allow external event loops control ZMQ communications layer.
>
>
> Implementation
> --------------
> Add two new functions:
>
> int zmq_poll_prepare(pollfd* fds_, zmq_pollitem_t *items_, int nitems_,
> int* zmq_signaler_fd_);
> Initialize the fds_ array of size nitems_ with file
> descriptors from items_. If there are ZMQ sockets in the items_
> array, *zmq_signaler_fd_ will contain the index of the ZMQ signaling
> fd. Otherwise *zmq_signaler_fd_ will be set to -1.
>
> int zmq_poll_check(pollfd* fd_, zmq_pollitem_t* item_, int event_,
> short type_)
> This function needs to be called after externally detected activity
> on event_. fd_ and item_ is the pollfd and zmq_pollitem_t structs
> corresponding to event_ item.
> The function will process internal ZMQ commands and update
> item_->revents corresponding to the type_ of event detected.
>
> I'd like to hear your feedback about adding this feature and can provide
> the implementation if there's interest of including it in the library.
>
> Serge



More information about the zeromq-dev mailing list