On Fri, Mar 25, 2016 at 7:21 PM, Alex Hultman <[email protected]> wrote: > Hi. > > This will be my third question regarding uv_tcp_t, thanks for all the quick > prior responses! > > I'm porting my project from uv_poll_t to uv_tcp_t and I'm not fully sold on > this uv_read_start function. It seems every uv_tcp_t should allocate its own > buffer? That is a big no no for me. > > Currently I share one single buffer over millions of connections, meaning I > have a very minimal memory usage per connection. When a uv_poll_t triggers > the UV_READABLE I simply read using Unix read into the shared buffer and > parse the contents. This seems impossible with uv_tcp_t? > > Can I use the same buffer for all uv_read_start? I cannot have every > uv_tcp_t allocate its own buffer, and that shouldn't be needed. The event > loop is serial, so only one read can be performed at any given time meaning > there is really no use to have separate buffers, as they will never > overwrite eachother.
Ownership of the buffer is with libuv between the uv_alloc_cb and uv_read_cb callbacks. That means you can reuse it in your uv_read_cb but not before. On UNIX, there is currently never any overlap so you won't need more than one buffer, although you should consider that an implementation detail. On Windows however, read requests can sometimes overlap. -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
