[nanomsg] Re: why memcpy data to be sent?
- From: Matthew Hall <mhall@xxxxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Tue, 28 Oct 2014 22:13:48 -0700
On Wed, Oct 29, 2014 at 05:44:32AM +0100, Martin Sustrik wrote:
> I feel your pain, but adding callbacks to the existing POSIX API isn't
> a good idea.
>
> Let's rather think about how to make customising nanomsg to do
> deallocation in a different way easier.
>
> Martin
I'm open to anything if it can allow nanomsg to send from a buffer I agred to
"protect" until it's done for it to do its job. But generally the way I saw it
done in the past used a callback or function pointer that could be plugged in
by the app to be used for malloc / free operations.
If there's a better way which doesn't pollute your nice API I am happy to hear
it. The POSIX equivalent would be something along the lines of using sbrk or
mmap to get "raw memory" which gets chunked for you by malloc, calloc, free,
etc. That wouldn't work in this case because I need to give nanomsg specific
chunks to transmit not "raw memory" in a big chunk.
So at some level we'd want a way of rerouting the alloc requests. If we can't
do it in the frontend, then the logical next option would be putting it in the
backend, but right now I think allocation is not pluggable and is handled
per-transport. It seems unpleasant to reimplement every transport just because
an app wants funny allocations.
But if somebody has a creative idea how to make it work with sgio / custom
alloc, I am happy to help however I can. I'm not a big expert on message
queueing but I'll try my best.
Matthew.
Other related posts:
