[zeromq-dev] zmsg_send() and send errors

AJ Lewis aj.lewis at quantum.com
Wed Aug 1 19:50:26 CEST 2012

I was staring at czmq's zmsg_send today, and it doesn't look
right to me.  It's of return type "void", which means
you can't ever get errors out of it - this seems wrong.

Can we look at changing the return type of zmsg_send() to be an
int?  I know that would break compatibility, so maybe that's a
non-starter.  If that's not an option, how about a new
zmsg_send_with_error() call (pick a better name please) that does
return the error up the stack to the caller?

Once a message gets back up to the caller, what is the state of
the message?  Does this mean the msg wasn't sent at all?  Is
there any way to abort the message at this point if several
frames were added before the error was hit?  It seems like it
might be safe to attempt to send the message again if the
ZFRAME_REUSE flag wasn't specified since all frames sent through
zmq_sendmsg should be destroyed, but there is still a potential
race condition there where the error (like EINTR) gets hit just
before the zframe_destroy is called.  Is this why we're not bothering
to send the error back up the chain?

This all works better since Mikko got 0b050b9 into the tree, but
taking it the next step and actually pushing the error up the stack
would be a good thing IMO.

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