[zeromq-dev] zmq_poll

Martin Sustrik sustrik at 250bpm.com
Fri May 21 07:36:15 CEST 2010

Hi Serge,

> Ok.  So how about the following API refinement?  Notably we're no longer 
> interested in passing around the context, but rather zmq_app_thread gets 
> us an app_thread that a 0MQ socket belongs to, and from there we can get 
> the signaling fd to be used for polling.
> // Return current application thread object or NULL if
> // current thread is not registered with the context
> void* zmq_app_thread(void* socket_);
> // Return file descriptor suitable for polling on to find
> // out if there's any outstanding work pending on app_thread_
> int zmq_wait_fd(void* app_thread_);
> // Process all pending commands in the context of
> // current application thread
> int zmq_process(void* app_thread_);
> // Determine if a socket as any pending events.
> // revents is a bitmask of ZMQ_POLLIN | ZMQ_POLLOUT
> int zmq_events(void* socket_, int revents);

Yes, that's better than before. I still feel that it can be improved 
somehow, but can't figure out how at the moment. Anyway, the 
functionality is OK and the change (if any) would be only cosmetic. So 
feel free to go on with the implementation.

> Will two 0MQ sockets of the same type share the same TCP transport 
> connection when connected to the same address?  Would it matter whether 
> or not they are owned by the same app_thread?

No. There will be two independent TCP conneccions.


More information about the zeromq-dev mailing list