Hi Serge,

> 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.

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.

2. However, it'll take some time to get that far. The problem with 
integrating 0MQ into foreign even loops should thus be solved (hacked) 
even before that.

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_);

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

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

Would that work with Erlang VM?

Martin
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Reply via email to