[zeromq-dev] zmq_poll
Serge Aleynikov
serge at aleynikov.org
Thu May 20 15:43:40 CEST 2010
See inline.
On 5/20/2010 1:54 AM, Martin Sustrik wrote:
> Obviously, this cannot be done for zmq_process as there is no socket
> passed in. Let's then think of a better API... what about zmq_wait_fd
> returning a handle aside of the fd? The handle would then be passed to
> zmq_process instead of context? That way the seatch for current app
> thread could be done once only at the beginning instead of repeating it
> over and over again in each zmq_process.
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);
> Unfortunately, design documents are missing. What happens is that each
> 0MQ socket (whatever type) has its own set of underlying TCP
> connections. These are never shared between distinct sockets.
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?
Serge
More information about the zeromq-dev
mailing list