[zeromq-dev] [zmqpp] receiving can only be done to empty messages?

[Matt Connolly]

As far as I understand, the purpose of EINTR is to force a blocking call to return so that the application can check for changes in state, such as time to shut down.

And, aren’t messages always delivered to the application together? i.e.: If there is a multipart message, aren’t we guaranteed that zmq will not block on the subsequent recv calls (until there is no more)?

If this is the case then it would make sense to do (1. on the first message) return EINTR to caller having received nothing; or (2. on subsequent messages) continue to read them and return to caller having received all of the message parts. In the latter case there would be no need to pass EINTR back to caller since the recv completed and returned.

-Matt

On 8 Jan 2014, at 8:14 pm, Ben Gray <ben at benjamg.com> wrote:

> 
> 
> 
> On 7 January 2014 17:06, Lindley French <lindleyf at gmail.com> wrote:
> At the same time I'm going to strongly suggest reviewing the assertion:
> assert(EAGAIN == zmq_errno());
> in the same function. I'm frequently getting EINTR here and failing the assertion when I run in gdb. (I think gdb throws a lot more signals than you'd normally get.)
> 
> 
> 
> I'm pretty sure the assert should be checking we never get EAGAIN on anything but the first frame of a message, which means the assert should be inverted as it's doing the opposite right now.
> 
> It also looks as though the socket will have read the first few frames of a message on an exception from anything but the first part. This leaves it in a state not particularly useful for zmqpp.
>  This is also true of sending, although in that case I'm pretty sure the only error code should be the EINTR so there might be something clever we can do to fix that.
> 
> What are peoples thoughts on this? there isn't exactly a way to roll back receiving or sending of the first X frames on a message.
> Possibly a function to query for incomplete messages and to allow sending / receiving of the remainder of a message?
> 
> Theoretically we could retry that frame on EINTR but I'd be hesitant to do that as it means ignoring the signal raised until the whole message is processed.
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140108/9e5f1d28/attachment.htm>