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. Thanks, -- AJ Lewis Software Engineer Quantum Corporation Work: 651 688-4346 email: [email protected] ---------------------------------------------------------------------- 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. _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
