Ben, How does it break bump allocation? You just bump the pointer and give the old value to uv_read(), right?
The proposed API is technically *identical* to the old one. On Mon, Jun 30, 2014 at 1:42 PM, Ben Noordhuis <[email protected]> wrote: > On Mon, Jun 30, 2014 at 9:28 AM, Saúl Ibarra Corretgé <[email protected]> > wrote: > > https://gist.github.com/saghul/909502cc7367a25c247a > > A hearty +1 from me but let me point out that the suggested function > prototype of uv_read() requires that the memory is committed upfront, > bump pointer allocation/release around the actual read won't work. > Adding a second uv_read() function that takes an uv_alloc_cb would > make that use case possible again. > > On the other hand, not many libuv users seem to do bump pointer / slab > allocation. Node.js may have been the only one and it no longer does. > > You could take a reactionary approach and not do anything until > someone complains. It should be fairly trivial to add later on, by > implementing `uv_read(uv_buf_t* bufs)` in terms of > `uv_read_alloc(uv_alloc_cb alloc_cb)`. Just make sure you leave some > room in the uv_read_t for future additions. > > -- > 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 http://groups.google.com/group/libuv. > For more options, visit https://groups.google.com/d/optout. > -- 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 http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
