Again, it is exactly the same :) But gives you more control of the situation.
You just give it the chunk and shrink the stuff in a callback of uv_read(), you just need to call alloc_cb yourself, this is the only thing that has changed. On Mon, Jun 30, 2014 at 4:09 PM, Ben Noordhuis <[email protected]> wrote: > On Mon, Jun 30, 2014 at 11:52 AM, Fedor Indutny <[email protected]> wrote: > > How does it break bump allocation? You just bump the pointer and give the > > old value to uv_read(), right? > > With uv_read_start(), the alloc_cb usually gets called right before > the read_cb. You can (ab)use that fact to implement a slab allocator, > where you return a large slice in your alloc_cb, then shrink it to fit > in your read_cb. In pseudo-code: > > def alloc_cb(): > buf = slab.used > slab.used += 65536 > return buf > > def read_cb(buf, nread): > slab.used -= len(buf) - nread > > With the proposed uv_read(), you have to commit the memory upfront. > That makes a slab allocator much less effective because concurrent > read requests will fragment the slab. > > -- > 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.
