On Wed, Feb 28, 2018 at 7:35 PM, <[email protected]> wrote: > The difference is that previously you could resize a segment without > adjusting any pointers. (Now, pointers into the next segment will > change their targets.) Conversely, if you allocated too big a buffer > for a segment, you could just ignore the extra part. (Now, again, you > have to write/transmit the padding, or pointers into the next segment > will get invalid.) >
The usual usage pattern here is that you allocate space for a segment, progressively fill it, and when you're out of space, then you allocate the next segment. Some space might be left over at the end of an allocated block if the objects didn't fit just right, but that space is not included in the serialized message. Under my proposal, this all works the same. Admittedly, the current implementation is able to "go back" to previous segments sometimes and fill in space that was left empty before, if the objects happen to fit right. That's still possible under the new model too, but harder: the extra space has to be treated as a new segment, which just happens to be part of the same memory allocation. In most cases it probably makes more sense to ignore the wasted space; if you allocate each segment to be twice the size of the last, then the wasted memory will amortize away. > (For some reason I was thinking about Linux-specific asynchronous > scatter/gather I/O, which _is_ a pain to use.) > Eh, it's only a pain in that there's a limit on how many buffers you can pass per syscall, but I've handled that in the library. (Windows, OTOH, doesn't seem to support scatter/gather except with some very finicky requirements that are unrealistic.) -Kenton -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/capnproto.
