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

Ben Gray ben at benjamg.com
Wed Jan 8 11:37:31 CET 2014


It's true we will have the whole message so will not enter a blocking state
if we continue to send / recv the individual frames of a multipart message
after an EINTR error code.


On 8 January 2014 10:29, Matt Connolly <matt.connolly at me.com> wrote:

> 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
>
>
>
> _______________________________________________
> 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/173d5370/attachment.htm>


More information about the zeromq-dev mailing list