Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD?

[Doron Somech]

Only if you are using thread safe sockets. You can save a call by with just
calling with ZMQ_NOBLOCK (no need for ZMQ_EVENTS). Then you don't need to
worry about race condition.
On May 24, 2016 08:22, "Huttunen, Kalle (GE Healthcare)" <
kalle.huttu...@ge.com> wrote:

> > after your call to zmq_recv(), but before your call to select() / poll()
>
>
>
> Are you talking about the way to receive messages when the ZMQ_FD signals?
> Basically I currently have the following code called when the ZMQ_FD
> becomes readable (in pseudocode):
>
>
>
> while ZMQ_EVENTS has ZMQ_POLLIN bit set
>
> {
>
> receive message from socket;
>
> process message;
>
> }
>
>
>
> Is there a potential race condition here?
>
>
>
> Thanks,
>
> --
>
> Kalle Huttunen
>
>
>
> *From:* zeromq-dev [mailto:zeromq-dev-boun...@lists.zeromq.org] *On
> Behalf Of *Dave Lambley
> *Sent:* 23. toukokuuta 2016 19:08
> *To:* ZeroMQ development list
> *Subject:* EXT: Re: [zeromq-dev] What are the “serious caveats” with
> ZMQ_FD?
>
>
>
> On 23 May 2016 at 10:23, Huttunen, Kalle (GE Healthcare) <
> kalle.huttu...@ge.com> wrote:
>
> It seems that sending on the socket makes the ZMQ_FD readable. That in
> turn triggers the calling of the code where I check ZMQ_EVENTS and receive
> everything from the socket. This way I end up checking ZMQ_EVENTS after
> each send.
>
> Is the ZMQ_FD becoming readable when sending on the socket something that
> can be relied on?
>
>
>
> I believe you have a race condition. If a message arrives after your call
> to zmq_recv(), but before your call to select() / poll(), it will block
> despite there being a message ready.
>
> If you can tolerate messages being delayed, there is an simple workaround
> in which you call zmq_recv() periodically. We have code doing this by
> specifying a timeout in the select() call.
>
> Dave
>
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] What are the “serious caveats” with ZMQ_FD?

[Huttunen, Kalle (GE Healthcare)]

> after your call to zmq_recv(), but before your call to select() / poll()

Are you talking about the way to receive messages when the ZMQ_FD signals? 
Basically I currently have the following code called when the ZMQ_FD becomes 
readable (in pseudocode):

while ZMQ_EVENTS has ZMQ_POLLIN bit set
{
receive message from socket;
process message;
}

Is there a potential race condition here?

Thanks,
--
Kalle Huttunen

From: zeromq-dev [mailto:zeromq-dev-boun...@lists.zeromq.org] On Behalf Of Dave 
Lambley
Sent: 23. toukokuuta 2016 19:08
To: ZeroMQ development list
Subject: EXT: Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD?

On 23 May 2016 at 10:23, Huttunen, Kalle (GE Healthcare) 
<kalle.huttu...@ge.com<mailto:kalle.huttu...@ge.com>> wrote:
It seems that sending on the socket makes the ZMQ_FD readable. That in turn 
triggers the calling of the code where I check ZMQ_EVENTS and receive 
everything from the socket. This way I end up checking ZMQ_EVENTS after each 
send.

Is the ZMQ_FD becoming readable when sending on the socket something that can 
be relied on?

I believe you have a race condition. If a message arrives after your call to 
zmq_recv(), but before your call to select() / poll(), it will block despite 
there being a message ready.
If you can tolerate messages being delayed, there is an simple workaround in 
which you call zmq_recv() periodically. We have code doing this by specifying a 
timeout in the select() call.
Dave

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

Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD?

[Dave Lambley]

On 23 May 2016 at 10:23, Huttunen, Kalle (GE Healthcare) <
kalle.huttu...@ge.com> wrote:

> It seems that sending on the socket makes the ZMQ_FD readable. That in
> turn triggers the calling of the code where I check ZMQ_EVENTS and receive
> everything from the socket. This way I end up checking ZMQ_EVENTS after
> each send.
>
> Is the ZMQ_FD becoming readable when sending on the socket something that
> can be relied on?
>

I believe you have a race condition. If a message arrives after your call
to zmq_recv(), but before your call to select() / poll(), it will block
despite there being a message ready.

If you can tolerate messages being delayed, there is an simple workaround
in which you call zmq_recv() periodically. We have code doing this by
specifying a timeout in the select() call.

Dave
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD?

[Justin Karneges]

I would not rely on this. Query ZMQ_EVENTS after every send no matter
what.

On Mon, May 23, 2016, at 02:23 AM, Huttunen, Kalle (GE Healthcare)
wrote:
> It seems that sending on the socket makes the ZMQ_FD readable. That in
> turn triggers the calling of the code where I check ZMQ_EVENTS and
> receive everything from the socket. This way I end up checking ZMQ_EVENTS
> after each send.
> 
> Is the ZMQ_FD becoming readable when sending on the socket something that
> can be relied on?
> 
> -- 
> Kalle Huttunen
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD?

[Huttunen, Kalle (GE Healthcare)]

It seems that sending on the socket makes the ZMQ_FD readable. That in turn 
triggers the calling of the code where I check ZMQ_EVENTS and receive 
everything from the socket. This way I end up checking ZMQ_EVENTS after each 
send.

Is the ZMQ_FD becoming readable when sending on the socket something that can 
be relied on?

-- 
Kalle Huttunen
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD?

[KIU Shueng Chuan]

In pseudocode, it might look like this:

void check_events(zsock)
{
  int revents = zsock.getsockopt(ZMQ_EVENTS);
  if (revents & ZMQ_POLLIN) {
  // "call_later" is some function that processes the call in the
  // next iteration of your event loop.
call_later(on_readable);
  }
}

// call this callback when the ZMQ_FD is readable
void on_readable(zsock)
{
  int revents = zsock.getsockopt(ZMQ_EVENTS);
  if (revents & ZMQ_POLLIN) {
// call zmq_recv() repeatedly to receive all frames of a multipart message
  }
  check_events(zsock);
}

void do_send(zsock, msg)
{
  zsock.send(msg);
  check_events(zsock);
}


On 2 May 2016 4:25 pm, "Kalle Huttunen"  wrote:

So basically I will just write (I use the C++ bindings):

mySocket.send(myMsg);
mySocket.getsockopt(ZMQ_EVENTS); // Update the file descriptor state

?

-- 
Kalle Huttunen


ma 2. toukokuuta 2016 klo 11.15 Justin Karneges  kirjoitti:
>
> "update the state" is strange wording but it means you need to query 
> ZMQ_EVENTS.
>
> And yes, you should assume that even a call to zmq_recv() might yield a 
> situation where there is more to read, but the fd doesn't become readable. 
> Basically, check ZMQ_EVENTS after every call to zmq_send or zmq_recv, and 
> whenever the fd becomes readable, regardless of which events you are 
> interested in.
>
> On Mon, May 2, 2016, at 01:07 AM, Kalle Huttunen wrote:
>
> Okay, this one I missed because I was looking at an old version of the man 
> page (http://api.zeromq.org/master:zmq-getsockopt takes you to 2.2.0 man 
> page).
>
> Full quote from the 4.1.5 man page (http://api.zeromq.org/4-1:zmq-getsockopt):
>
> "The returned file descriptor is also used internally by the zmq_send and 
> zmq_recv functions. As the descriptor is edge triggered, applications must 
> update the state of ZMQ_EVENTS after each invocation of zmq_send or 
> zmq_recv.To be more explicit: after calling zmq_send the socket may become 
> readable (and vice versa) without triggering a read event on the file 
> descriptor."
>
> This definitely sounds like a caveat I should handle. The quote raises some 
> questions, though:
>
> - What exactly does it mean to "update the state of ZMQ_EVENTS"?
>
> - Do both zmq_send() and zmq_recv() reset all events in the FD? So if I'm 
> only interested on events about incoming messages (I check only ZMQ_POLLIN 
> from ZMQ_EVENTS), do I need to "update the state of ZMQ_EVENTS" after both 
> zmq_send() and zmq_recv(), or is it enough to do it only after zmq_send()?
>
> --
> Kalle Huttunen
>
> ma 2. toukokuuta 2016 klo 4.16 KIU Shueng Chuan  
> kirjoitti:
>
> From the man page for zmq_getsockopt:
>
> "after calling zmq_send the socket may become readable (and vice versa) 
> without triggering a read event on the file descriptor."
>
>
> On 1 May 2016 3:33 am, "Kalle Huttunen"  wrote:
>
> The ZeroMQ FAQ (http://zeromq.org/area:faq#toc5) states in the "Why can't I 
> use standard I/O multiplexing functions such as select() or poll() on ZeroMQ 
> sockets?" question:
>
> > Note that there's a way to retrieve a file descriptor from ZeroMQ socket 
> > (ZMQ_FD socket option) that you can poll on from version 2.1 onwards, 
> > however, there are some serious caveats when using it. Check the 
> > documentation carefully before using this feature.
>
> I've prototyped integrating ZeroMQ socket receiving to Qt's and custom 
> select() based event loops, and on the first glance everything seems to work.
>
> From the documentation I have identified two "caveats" that I handle in my 
> code:
>
> 1. The ability to read from the returned file descriptor does not necessarily 
> indicate that messages are available to be read from the socket
>
> This I have solved by checking ZMQ_EVENTS before reading from the socket.
>
> 2. Events are signaled in edge-triggered fashion
>
> This one I have solved by always receiving all the messages from the socket 
> when the file descriptor signals.
>
> Are there some caveats that I'm missing?
>
> --
> Kalle Huttunen
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev


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

Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD?

[Jim Hague]

On Saturday 30 Apr 2016 19:32:56 Kalle Huttunen wrote:
> I've prototyped integrating ZeroMQ socket receiving to Qt's and custom
> select() based event loops, and on the first glance everything seems to
> work.
> 
> From the documentation I have identified two "caveats" that I handle in my
> code [...]
>
> Are there some caveats that I'm missing?

One little thing that tripped me up. If you're using PGM, sending though a PUB 
and listening for incoming traffic on a SUB, you might think you only need to 
monitor the FD on the SUB socket. In fact any NAK from a client gets sent to 
the PUB socket, so you need to monitor it's FD for incoming traffic too. Using 
either to trigger calling zmq_poll() on the SUB socket will get NAK responses 
sent properly.

If you don't monitor the PUB socket FD, only call zmq_recv() or zmq_poll() on 
an event, and don't have any traffic to zmq_send(), PGM NAKs won't get 
processed.
-- 
Jim Hague - jim.ha...@acm.org  Never trust a computer you can't lift.

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

Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD?

[Kalle Huttunen]

So basically I will just write (I use the C++ bindings):

mySocket.send(myMsg);
mySocket.getsockopt(ZMQ_EVENTS); // Update the file descriptor state

?

-- 
Kalle Huttunen


ma 2. toukokuuta 2016 klo 11.15 Justin Karneges 
kirjoitti:

> "update the state" is strange wording but it means you need to query
> ZMQ_EVENTS.
>
> And yes, you should assume that even a call to zmq_recv() might yield a
> situation where there is more to read, but the fd doesn't become readable.
> Basically, check ZMQ_EVENTS after every call to zmq_send or zmq_recv, and
> whenever the fd becomes readable, regardless of which events you are
> interested in.
>
> On Mon, May 2, 2016, at 01:07 AM, Kalle Huttunen wrote:
>
> Okay, this one I missed because I was looking at an old version of the man
> page (http://api.zeromq.org/master:zmq-getsockopt takes you to 2.2.0 man
> page).
>
> Full quote from the 4.1.5 man page (
> http://api.zeromq.org/4-1:zmq-getsockopt):
>
> "The returned file descriptor is also used internally by the zmq_send and
> zmq_recv functions. As the descriptor is edge triggered, applications must
> update the state of ZMQ_EVENTS after each invocation of zmq_send or
> zmq_recv.To be more explicit: after calling zmq_send the socket may become
> readable (and vice versa) without triggering a read event on the file
> descriptor."
>
> This definitely sounds like a caveat I should handle. The quote raises
> some questions, though:
>
> - What exactly does it mean to "update the state of ZMQ_EVENTS"?
>
> - Do both zmq_send() and zmq_recv() reset all events in the FD? So if I'm
> only interested on events about incoming messages (I check only ZMQ_POLLIN
> from ZMQ_EVENTS), do I need to "update the state of ZMQ_EVENTS" after
> both zmq_send() and zmq_recv(), or is it enough to do it only after
> zmq_send()?
>
> --
> Kalle Huttunen
>
> ma 2. toukokuuta 2016 klo 4.16 KIU Shueng Chuan 
> kirjoitti:
>
> From the man page for zmq_getsockopt:
>
> "after calling zmq_send the socket may become readable (and vice versa)
> without triggering a read event on the file descriptor."
>
> On 1 May 2016 3:33 am, "Kalle Huttunen"  wrote:
>
> The ZeroMQ FAQ (http://zeromq.org/area:faq#toc5) states in the "Why can't
> I use standard I/O multiplexing functions such as select() or poll() on
> ZeroMQ sockets?" question:
>
> > Note that there's a way to retrieve a file descriptor from ZeroMQ socket
> (ZMQ_FD socket option) that you can poll on from version 2.1 onwards,
> however, there are some serious caveats when using it. Check the
> documentation carefully before using this feature.
>
> I've prototyped integrating ZeroMQ socket receiving to Qt's and custom
> select() based event loops, and on the first glance everything seems to
> work.
>
> From the documentation I have identified two "caveats" that I handle in my
> code:
>
> 1. The ability to read from the returned file descriptor does not
> necessarily indicate that messages are available to be read from the socket
>
> This I have solved by checking ZMQ_EVENTS before reading from the socket.
>
> 2. Events are signaled in edge-triggered fashion
>
> This one I have solved by always receiving all the messages from the
> socket when the file descriptor signals.
>
> Are there some caveats that I'm missing?
>
> --
> Kalle Huttunen
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> *___*
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD?

[Justin Karneges]

"update the state" is strange wording but it means you need to query
ZMQ_EVENTS.
 
And yes, you should assume that even a call to zmq_recv() might yield a
situation where there is more to read, but the fd doesn't become
readable. Basically, check ZMQ_EVENTS after every call to zmq_send or
zmq_recv, and whenever the fd becomes readable, regardless of which
events you are interested in.
 
On Mon, May 2, 2016, at 01:07 AM, Kalle Huttunen wrote:
> Okay, this one I missed because I was looking at an old version of the
> man page (http://api.zeromq.org/master:zmq-getsockopt takes you to
> 2.2.0 man page).
>
> Full quote from the 4.1.5 man page
> (http://api.zeromq.org/4-1:zmq-getsockopt):
>
> "The returned file descriptor is also used internally by the zmq_send
> and zmq_recv functions. As the descriptor is edge triggered,
> applications must update the state of ZMQ_EVENTS after each invocation
> of zmq_send or zmq_recv.To be more explicit: after calling zmq_send
> the socket may become readable (and vice versa) without triggering a
> read event on the file descriptor."
>
> This definitely sounds like a caveat I should handle. The quote raises
> some questions, though:
>
> - What exactly does it mean to "update the state of ZMQ_EVENTS"?
>
> - Do both zmq_send() and zmq_recv() reset all events in the FD? So if
>   I'm only interested on events about incoming messages (I check only
>   ZMQ_POLLIN from ZMQ_EVENTS), do I need to "update the state of
>   ZMQ_EVENTS" after both zmq_send() and zmq_recv(), or is it enough to
>   do it only after zmq_send()?
>
> --
> Kalle Huttunen
>
> ma 2. toukokuuta 2016 klo 4.16 KIU Shueng Chuan 
> kirjoitti:
>> From the man page for zmq_getsockopt:
>> "after calling zmq_send the socket may become readable (and vice
>> versa) without triggering a read event on the file descriptor."
>>
>> On 1 May 2016 3:33 am, "Kalle Huttunen"  wrote:
>>> The ZeroMQ FAQ (http://zeromq.org/area:faq#toc5) states in the "Why
>>> can't I use standard I/O multiplexing functions such as select() or
>>> poll() on ZeroMQ sockets?" question:
>>>
>>> > Note that there's a way to retrieve a file descriptor from ZeroMQ
>>> > socket (ZMQ_FD socket option) that you can poll on from version
>>> > 2.1 onwards, however, there are some serious caveats when using
>>> > it. Check the documentation carefully before using this feature.
>>>
>>> I've prototyped integrating ZeroMQ socket receiving to Qt's and
>>> custom select() based event loops, and on the first glance
>>> everything seems to work.
>>>
>>> From the documentation I have identified two "caveats" that I handle
>>> in my code:
>>>
>>> 1. The ability to read from the returned file descriptor does not
>>>necessarily indicate that messages are available to be read from
>>>the socket
>>>
>>> This I have solved by checking ZMQ_EVENTS before reading from the
>>> socket.
>>>
>>> 2. Events are signaled in edge-triggered fashion
>>>
>>> This one I have solved by always receiving all the messages from the
>>> socket when the file descriptor signals.
>>>
>>> Are there some caveats that I'm missing?
>>>
>>> --
>>> Kalle Huttunen
>>>
>>> ___
>>>  zeromq-dev mailing list
>>> zeromq-dev@lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> ___
>>  zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
 
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD?

[Kalle Huttunen]

Okay, this one I missed because I was looking at an old version of the man
page (http://api.zeromq.org/master:zmq-getsockopt takes you to 2.2.0 man
page).

Full quote from the 4.1.5 man page (http://api.zeromq.org/4-1:zmq-getsockopt
):

"The returned file descriptor is also used internally by the zmq_send and
zmq_recv functions. As the descriptor is edge triggered, applications must
update the state of ZMQ_EVENTS after each invocation of zmq_send or
zmq_recv.To be more explicit: after calling zmq_send the socket may become
readable (and vice versa) without triggering a read event on the file
descriptor."

This definitely sounds like a caveat I should handle. The quote raises some
questions, though:

- What exactly does it mean to "update the state of ZMQ_EVENTS"?

- Do both zmq_send() and zmq_recv() reset all events in the FD? So if I'm
only interested on events about incoming messages (I check only ZMQ_POLLIN
from ZMQ_EVENTS), do I need to "update the state of ZMQ_EVENTS" after both
zmq_send() and zmq_recv(), or is it enough to do it only after zmq_send()?

-- 
Kalle Huttunen

ma 2. toukokuuta 2016 klo 4.16 KIU Shueng Chuan 
kirjoitti:

> From the man page for zmq_getsockopt:
>
> "after calling zmq_send the socket may become readable (and vice versa)
> without triggering a read event on the file descriptor."
> On 1 May 2016 3:33 am, "Kalle Huttunen"  wrote:
>
>> The ZeroMQ FAQ (http://zeromq.org/area:faq#toc5) states in the "Why
>> can't I use standard I/O multiplexing functions such as select() or poll()
>> on ZeroMQ sockets?" question:
>>
>> > Note that there's a way to retrieve a file descriptor from ZeroMQ
>> socket (ZMQ_FD socket option) that you can poll on from version 2.1
>> onwards, however, there are some serious caveats when using it. Check the
>> documentation carefully before using this feature.
>>
>> I've prototyped integrating ZeroMQ socket receiving to Qt's and custom
>> select() based event loops, and on the first glance everything seems to
>> work.
>>
>> From the documentation I have identified two "caveats" that I handle in
>> my code:
>>
>> 1. The ability to read from the returned file descriptor does not
>> necessarily indicate that messages are available to be read from the socket
>>
>> This I have solved by checking ZMQ_EVENTS before reading from the socket.
>>
>> 2. Events are signaled in edge-triggered fashion
>>
>> This one I have solved by always receiving all the messages from the
>> socket when the file descriptor signals.
>>
>> Are there some caveats that I'm missing?
>>
>> --
>> Kalle Huttunen
>>
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD?

[KIU Shueng Chuan]

>From the man page for zmq_getsockopt:

"after calling zmq_send the socket may become readable (and vice versa)
without triggering a read event on the file descriptor."
On 1 May 2016 3:33 am, "Kalle Huttunen"  wrote:

> The ZeroMQ FAQ (http://zeromq.org/area:faq#toc5) states in the "Why can't
> I use standard I/O multiplexing functions such as select() or poll() on
> ZeroMQ sockets?" question:
>
> > Note that there's a way to retrieve a file descriptor from ZeroMQ socket
> (ZMQ_FD socket option) that you can poll on from version 2.1 onwards,
> however, there are some serious caveats when using it. Check the
> documentation carefully before using this feature.
>
> I've prototyped integrating ZeroMQ socket receiving to Qt's and custom
> select() based event loops, and on the first glance everything seems to
> work.
>
> From the documentation I have identified two "caveats" that I handle in my
> code:
>
> 1. The ability to read from the returned file descriptor does not
> necessarily indicate that messages are available to be read from the socket
>
> This I have solved by checking ZMQ_EVENTS before reading from the socket.
>
> 2. Events are signaled in edge-triggered fashion
>
> This one I have solved by always receiving all the messages from the
> socket when the file descriptor signals.
>
> Are there some caveats that I'm missing?
>
> --
> Kalle Huttunen
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD?

[Justin Karneges]

I believe multipart messages are treated atomically, which means if
you're able to receive the first part then you're able to receive all
the remaining parts immediately. When QZmq was first written I was not
aware of the atomic handling, and so the code is probably more complex
than it needs to be.
 
On Sat, Apr 30, 2016, at 11:45 PM, Kalle Huttunen wrote:
> Hi, thanks for your answer. The README of your QZmq project rises up
> an interesting point: multipart messages. How do they work in relation
> to ZMQ_FD? When the FD signals read, have all message parts been
> received?
>
> --
> Kalle Huttunen
>
> la 30. huhtikuuta 2016 klo 23.16 Justin Karneges 
> kirjoitti:
>> __
>> Expanding on your first point: the file descriptor only triggers read
>> notifications, and the notification means to query ZMQ_EVENTS. For
>> example, when a zmq socket becomes writable, the ZMQ_FD file
>> descriptor becomes readable, and you react to that by checking
>> ZMQ_EVENTS and discover the zmq socket can be written to.
>>
>> Also you may be interested in https://github.com/jkarneges/qzmq
>>
>> On Sat, Apr 30, 2016, at 12:32 PM, Kalle Huttunen wrote:
>>> The ZeroMQ FAQ (http://zeromq.org/area:faq#toc5) states in the "Why
>>> can't I use standard I/O multiplexing functions such as select() or
>>> poll() on ZeroMQ sockets?" question:
>>>
>>> > Note that there's a way to retrieve a file descriptor from ZeroMQ
>>> > socket (ZMQ_FD socket option) that you can poll on from version
>>> > 2.1 onwards, however, there are some serious caveats when using
>>> > it. Check the documentation carefully before using this feature.
>>>
>>> I've prototyped integrating ZeroMQ socket receiving to Qt's and
>>> custom select() based event loops, and on the first glance
>>> everything seems to work.
>>>
>>> From the documentation I have identified two "caveats" that I handle
>>> in my code:
>>>
>>> 1. The ability to read from the returned file descriptor does not
>>>necessarily indicate that messages are available to be read from
>>>the socket
>>>
>>> This I have solved by checking ZMQ_EVENTS before reading from the
>>> socket.
>>>
>>> 2. Events are signaled in edge-triggered fashion
>>>
>>> This one I have solved by always receiving all the messages from the
>>> socket when the file descriptor signals.
>>>
>>> Are there some caveats that I'm missing?
>>>
>>> --
>>> Kalle Huttunen
>>> _
>>> zeromq-dev mailing list
>>> zeromq-dev@lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>> ___
>>  zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
 
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD?

[Kalle Huttunen]

Hi, thanks for your answer. The README of your QZmq project rises up an
interesting point: multipart messages. How do they work in relation to
ZMQ_FD? When the FD signals read, have all message parts been received?

-- 
Kalle Huttunen

la 30. huhtikuuta 2016 klo 23.16 Justin Karneges 
kirjoitti:

> Expanding on your first point: the file descriptor only triggers read
> notifications, and the notification means to query ZMQ_EVENTS. For example,
> when a zmq socket becomes writable, the ZMQ_FD file descriptor becomes
> readable, and you react to that by checking ZMQ_EVENTS and discover the zmq
> socket can be written to.
>
> Also you may be interested in https://github.com/jkarneges/qzmq
>
> On Sat, Apr 30, 2016, at 12:32 PM, Kalle Huttunen wrote:
>
> The ZeroMQ FAQ (http://zeromq.org/area:faq#toc5) states in the "Why can't
> I use standard I/O multiplexing functions such as select() or poll() on
> ZeroMQ sockets?" question:
>
> > Note that there's a way to retrieve a file descriptor from ZeroMQ socket
> (ZMQ_FD socket option) that you can poll on from version 2.1 onwards,
> however, there are some serious caveats when using it. Check the
> documentation carefully before using this feature.
>
> I've prototyped integrating ZeroMQ socket receiving to Qt's and custom
> select() based event loops, and on the first glance everything seems to
> work.
>
> From the documentation I have identified two "caveats" that I handle in my
> code:
>
> 1. The ability to read from the returned file descriptor does not
> necessarily indicate that messages are available to be read from the socket
>
> This I have solved by checking ZMQ_EVENTS before reading from the socket.
>
> 2. Events are signaled in edge-triggered fashion
>
> This one I have solved by always receiving all the messages from the
> socket when the file descriptor signals.
>
> Are there some caveats that I'm missing?
>
> --
> Kalle Huttunen
>
> *___*
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD?

[Justin Karneges]

Expanding on your first point: the file descriptor only triggers read
notifications, and the notification means to query ZMQ_EVENTS. For
example, when a zmq socket becomes writable, the ZMQ_FD file descriptor
becomes readable, and you react to that by checking ZMQ_EVENTS and
discover the zmq socket can be written to.
 
Also you may be interested in https://github.com/jkarneges/qzmq
 
On Sat, Apr 30, 2016, at 12:32 PM, Kalle Huttunen wrote:
> The ZeroMQ FAQ (http://zeromq.org/area:faq#toc5) states in the "Why
> can't I use standard I/O multiplexing functions such as select() or
> poll() on ZeroMQ sockets?" question:
>
> > Note that there's a way to retrieve a file descriptor from ZeroMQ
> > socket (ZMQ_FD socket option) that you can poll on from version 2.1
> > onwards, however, there are some serious caveats when using it.
> > Check the documentation carefully before using this feature.
>
> I've prototyped integrating ZeroMQ socket receiving to Qt's and custom
> select() based event loops, and on the first glance everything seems
> to work.
>
> From the documentation I have identified two "caveats" that I handle
> in my code:
>
> 1. The ability to read from the returned file descriptor does not
>necessarily indicate that messages are available to be read from
>the socket
>
> This I have solved by checking ZMQ_EVENTS before reading from
> the socket.
>
> 2. Events are signaled in edge-triggered fashion
>
> This one I have solved by always receiving all the messages from the
> socket when the file descriptor signals.
>
> Are there some caveats that I'm missing?
>
> --
> Kalle Huttunen
> _
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
 
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] What are the “serious caveats” with ZMQ_FD?

[Kalle Huttunen]

The ZeroMQ FAQ (http://zeromq.org/area:faq#toc5) states in the "Why can't I
use standard I/O multiplexing functions such as select() or poll() on
ZeroMQ sockets?" question:

> Note that there's a way to retrieve a file descriptor from ZeroMQ socket
(ZMQ_FD socket option) that you can poll on from version 2.1 onwards,
however, there are some serious caveats when using it. Check the
documentation carefully before using this feature.

I've prototyped integrating ZeroMQ socket receiving to Qt's and custom
select() based event loops, and on the first glance everything seems to
work.

>From the documentation I have identified two "caveats" that I handle in my
code:

1. The ability to read from the returned file descriptor does not
necessarily indicate that messages are available to be read from the socket

This I have solved by checking ZMQ_EVENTS before reading from the socket.

2. Events are signaled in edge-triggered fashion

This one I have solved by always receiving all the messages from the socket
when the file descriptor signals.

Are there some caveats that I'm missing?

-- 
Kalle Huttunen
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev