Closed ReimuNotMoe closed 1 year ago
Uhm, from what I see, we use it with uv_read_start
and uv_udp_recv_start
, that is, stream_handle<...>::read
and udp_handle::recv
.
The easiest thing to do is to accept a callback at the callsite probably. Passing around the buffer size is also possible but it should be an auto template argument to use to specialize common_alloc_callback
. It doesn't worth it imho.
Any other suggestions on how to implement it otherwise?
I can't think of other reasonable ways. Still I think allowing the user to set a callback is the best option, since this would allow the user to do further optimizations, such as using a memory pool. The next thing to worry about is how to provide the API, I'm fine with a new member function, and something like on<uvw::alloc_event>()
could also work but it would introduce extra overhead (shared_ptr+function) and it will be the only callback that doesn't have uvw handle as the first argument...
To be honest, I'd pass it as a function argument and mimic what libuv
does already under the hood. It looks cleaner than anything else. Doesn't it?
Yeah, I think so.
Also interested in this from a recvmmsg support perspective. We need to be able to provide a buffer that is a multiple of the max datagram size for recvmmsg to work correctly.
Hello. I'm trying to optimize the performance of uvw and libuv on low-ram (<64MiB) embedded platforms. Currently, all buffer allocations for stream handles are done by the
details::common_alloc_callback
function, and it just allocates as much ram as libuv suggested (64KiB). This is too big and undesirable on almost all embedded platforms. I wonder if it's possible to enable the user to specify the buffer size, or even better, use a user supplied allocation callback? Thanks.