[zeromq-dev] zmsg_send() and send errors

AJ Lewis aj.lewis at quantum.com
Mon Aug 6 15:34:27 CEST 2012

On Sun, Aug 05, 2012 at 01:22:31PM +0900, Pieter Hintjens wrote:
> On Fri, Aug 3, 2012 at 10:59 PM, Andrew Hume <andrew at research.att.com> wrote:
> > the issue is an old one: if i do a send, did it get there?  there
> > is only one way to answer that correctly, which is an end-to-end
> > scheme.  anything else is half-assed, and to the extent that
> > having a return would encourage folk to do a half-assed job, we
> > shouldn't.
> I tend to agree but will argue the other side; a return code is
> consistent with other layers that send messages.

Mainly it's to deal with signals in a sane manner, no?  We've seen
issues in the function because there used to be an assert when the
send failed (which was bad) and then we didn't assert on ETERM and
EINTR, but ignored the error in that case (which was bad too, as the
calling process couldn't handle the SIGTERM), and now we have the
case where zmsg_send returns on error, but there's no way to tell why
it returned - it could have been success or failure or signal

I'm still not sure how a caller is supposed to deal with a message
getting interrupted - if you're using a REQ socket and assume that
the message was sent, you'll hang waiting for the response if it
wasn't; and if you assume it wasn't sent and it was, you'll hang on
resend, right?  Any thoughts on how to handle that?
> I've created an issue https://github.com/zeromq/czmq/issues/58 and
> made a pull request.

Great - thank you!
AJ Lewis
Software Engineer
Quantum Corporation

Work:    651 688-4346
email:   aj.lewis at quantum.com

The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.

More information about the zeromq-dev mailing list