[nanomsg] Re: Changes to the API
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Wed, 23 Jan 2013 21:49:35 +0100
On 23/01/13 21:19, Paul Colomiets wrote:
Hi Martin,
On Wed, Jan 23, 2013 at 8:45 AM, Martin Sustrik<sustrik@xxxxxxxxxx> wrote:
nn_sendmsg and nn_recvmsg which were originally intended to send/recv
zero-copy buffers were changed to by fully compliant with POSIX. The support
gather/scatter arrays, control information (ancillary data) etc.
The problem with this API is not a function names, but the inability
to recv single message of any size without preallocating a buffer for
the biggest possible message. But nevermind.
What about this?
void *buf;
nn_recv (s, &buf, NN_MSG, 0);
...
nn_freemsg (buf);
Why not make NN_MSG a flag? Like the following:
void *buf = nn_allocmsg (10, 0);
memset (buf, 0xab, 10);
nn_send (s, buf, sizeof(buf), NN_MSG);
void *buf;
nn_recv (s,&buf, sizeof(buf), NN_MSG);
nn_freemsg (buf);
The problem with NN_MSG being length, this may lead to buggy code for
any wrapper library which is not robust enough to check for this value
explicitly. May be I explain not clear enough, but flag seems to be
more logical anyway.
The original reason was that nn_sendmsg and nn_recvmsg take array of
iovecs, where any of them can be either normal buffer or a zero-copy buffer.
However, in the meanwhile I've realised that if zero-copy is combined
with iovecs, the iovec array can have at most 1 buffer anyway. Thus the
flag makes sense.
One minor caveat is that the library is able to get the size of the
preallocated buffer from void* pointer alone, thus len parameter is kind
of redundant.
Martin
Other related posts:
