-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failure case behavior unclear in zmq_msg_send
documentation
#3526
Comments
It's implied: "NOTE: A successful invocation of zmq_msg_send() does not indicate that the In the successful case you don't need to call close and the library takes ownership. If it's not successful, the library hasn't taken ownership. Feel free to send a PR to clarify the text. |
Thanks for the quick response! I will try to submit a PR soonish. |
Solution: Explicitly explain message ownership semantics when the call fails. Fixes zeromq#3526.
Issue description
The documentation on
zmq_msg_send
is unclear about what happens to the provided message in the failure case. The manpage states:This seems to contradict the following snippet, which indicates that the message stays the responsibility of the caller in the failure case:
The question here is whether it is safe to assume that the message content stays available to the caller in the failure case. A particularly important case is EAGAIN -- it would be quite unfortunate if the caller had to reconstruct the message if it could not be sent simply to a timeout, although it would be unfortunate if that happened for any error, IMO.
I have not really attempted to dig into the code to verify this one way or the other, as it's not easy to follow given the inheritance hierarchy for sockets and other things going on.
It would be awesome if someone could confirm that my suspicion is right, and the message is preserved in all failure cases. I'd be willing to come up with a PR to clarify the wording in the documentation in that case.
This question originally came up in an issue in the Rust
zmq
crate, which provides bindings to libzmq:erickt/rust-zmq#211
Environment
The text was updated successfully, but these errors were encountered: