[zeromq-dev] zmq_msg_init: suggest to change interface
Chuck Remes
cremes.devlist at mac.com
Thu Jan 19 16:07:41 CET 2012
On Jan 19, 2012, at 8:33 AM, john skaller wrote:
> This interface:
>
> int zmq_msg_init (zmq_msg_t *msg);
>
> is really getting in my way. I have a "helper" function that
> receives messages. This function is part of the Felix binding for zmq.
>
> It has to create a message, initialise it,
> do the receive, close the message, and return the result, which is a pair:
>
> bytes_read, string
>
> where bytes_read can be -1 to indicate an error.
>
> The problem is, I cannot implement this helper function
> because I do not know what to do with the error code
> returned by zmq_msg_init. Only the application can know.
> [It's the same with zmq_msg_close]
>
> Of course I *could* return it. But it seems wrong.
Why is it wrong to bubble up an error code to the caller? You are going to have the same issue with nearly every other zmq_*() function that returns an error code, right?
> zmq_msg_init cannot fail. It has to initialise a structure full of
> random bytes, so there is no possible test for an error condition.
> AFAIK it can't run out of memory or anything either.
But that's an implementation detail about how it works *today*. Perhaps a future version will change the implementation under the covers and suddenly this call can fail due to memory limitations.
> So I'd like to suggest changing the interface to:
>
> void zmq_msg_init (zmq_msg_t *msg);
>
> In addition, I guess (??) a message initialised with this function
> can be re-initialised by one of the (other) initialisations functions,
> since it doesn't do anything except set some variables, so there
> are no resources to lose on a re-initialisation. So that should
> be explicitly permitted.
Again, this is a current implementation detail. I would not favor modifying the API at this time.
This API works for every other language binding that has been created. I think there are about 20 of them. Why is Felix so special? :)
cr
More information about the zeromq-dev
mailing list