[nanomsg] Re: why memcpy data to be sent?
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Mon, 27 Oct 2014 12:09:52 -0700
Sounds to me like you really should try to do a real Erlang port, instead of
just linking against libnanomsg. (Mangos did this for Go — I think its the
only port of nanomsg to another language that doesn’t make use of foreign
function calls.)
- Garrett
> On Oct 27, 2014, at 11:13 AM, Steve Vinoski <vinoski@xxxxxxxx> wrote:
>
>
>
> On Mon, Oct 27, 2014 at 12:27 PM, Dirkjan Ochtman <dirkjan@xxxxxxxxxx
> <mailto:dirkjan@xxxxxxxxxx>> wrote:
> On Mon, Oct 27, 2014 at 4:54 PM, Steve Vinoski <vinoski@xxxxxxxx
> <mailto:vinoski@xxxxxxxx>> wrote:
> > The reason I'm interested is that in the Erlang nanomsg driver, Erlang
> > naturally sends I/O vecs to the enm:send() function (i.e., the I/O vector is
> > essentially a built-in type in Erlang), and so passing them along directly
> > to nanomsg should mean very high efficiency and copy avoidance. So, it would
> > be very handy if the copying was either removed or if the caller could pass
> > a flag to say "I guarantee these data blocks will not be freed, please don't
> > copy them."
>
> Theoretically we have http://nanomsg.org/v0.4/nn_allocmsg.3.html
> <http://nanomsg.org/v0.4/nn_allocmsg.3.html> for
> this, right?
>
> Theoretically, yes, but this doesn't help at all when using nanomsg
> underneath other systems that do their own memory allocation. For my specific
> case of sending messages, the Erlang VM allocates the memory for the data as
> part of its per-lightweight-process GC system, and the Erlang VM passes
> pointers to those blocks to my driver which then passes them along to nanomsg.
>
> Maybe I'm missing something, but in looking at the nanomsg code some more I
> couldn't see any compelling reason for the copy other than the fact that the
> send functions called after the copy is made don't do the equivalent of
> writev and instead take just a single block of data.
>
> --steve
Other related posts:
