[zeromq-dev] full duplex asynch messaging

[Arun Jayaprakash]

Hi Martin,
    Thanks for you quick response. In my application there can be messages
to be sent and received at random unpredictable points of time (and in any
order) and they need to be processed with minimal latency.  The latter would
require me to call recv in a loop. The sends would come in from a separate
thread. From docs, i see that i can only access zmq_socket from the creating
thread. So this essentially needs the sender thread to enqueue its messages
somewhere , then the looping thread has to repeatedly initiate non blocking
recvs and chk send queue, then a (nonblocking) send  etc within a single
loop. That doesnt look like a very efficient design at the surface. I was
ideally looking for something which fits the below model.  Is there a
callback which can be registered when there are messages waiting to be read
? If not, do you have any suggestions for the above requirements?

// This method would be called by one single thread
sendMessage(msg)
{
     socket.send(msg);
}

// incoming message from network should
// call below method (from a specifed thread or pool)
// for boost asio , this is the thread/s which start io_service
messageFromNetworkCallback(msg)
{
     process_message (msg);
}
Regards
Arun

On Mon, Mar 15, 2010 at 3:46 PM, Martin Sustrik <sustrik at 250bpm.com> wrote:

> Arun,
>
>
>   Is there a way to achieve two way asynchronous send/receive on 0mq
>> sockets ? I currently use boost asio (proactor) which internally iocp/epolls
>> to achieve this.  zmq_poll does look promising, but is there an easier
>> method ?  Also how is the zmq_poll implemented internally ?
>>
>
> Send/receive IS asynchronous.
>
> Send doesn't block even if the message cannot be sent immediately. Instead,
> it queues the message and delivers it later on.
>
> Incoming messages are received even if recv function is not called. They
> are queued and returned by later call(s) to recv.
>
> However, AFAICS, you've probably had some other question in mind...
>
> As for zmq_poll, it checks whether there are messages in internal queues
> (POLLIN) or whether the queue limits are not yet reached (POLLOUT).
>
> Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100315/700318ba/attachment.htm>