[capnproto] Relations between num. calls to allocateSegment() and num. segments in getSegmentsForOutput()

[Junhyun Shim]

Hi,

I'm currently writing a custom impl. of MessageBuilder (with overridden
allocateSegment virtual method that produces moveable, shallow-cloneable
buffers),
that, after fleshing out the capnproto message as a whole, produces an
internal message object backed by a static array of those buffers for I/O.

As you might have noticed, this design builds on the assumption that the
number of segments produced by getSegmentsForOutput()
does not exceed the number of calls made to allocateSegment() while
building the message.
Is this a safe guarantee? Can I even go on to assume that the base pointers
produced by getSegmentsForOutput()
are exactly the same as allocated segments and the only variation is in
their sizes?

Or is there a chance that out-of-order initialization of root message
members might end up scrambling these orders?

Best regards,
Jun

['Kenton Varda' via Cap'n Proto]

Hi Junhyun,

I think that, at present, the only thing that would break your assumptions
is Orphanage::referenceExternalData(). You could, of course, document that
your MessageBuilder does not permit referencing external data.

Other than that, I think your assumptions currently hold -- but I don't
know if I'd be comfortable guaranteeing them. It's better if you can look
at what getSegmentForOutput() returns and handle any discrepancies between
that and what you were expecting.

-Kenton

Post by Junhyun Shim
Hi,
I'm currently writing a custom impl. of MessageBuilder (with overridden
allocateSegment virtual method that produces moveable, shallow-cloneable
buffers),
that, after fleshing out the capnproto message as a whole, produces an
internal message object backed by a static array of those buffers for I/O.
As you might have noticed, this design builds on the assumption that the
number of segments produced by getSegmentsForOutput()
does not exceed the number of calls made to allocateSegment() while
building the message.
Is this a safe guarantee? Can I even go on to assume that the base
pointers produced by getSegmentsForOutput()
are exactly the same as allocated segments and the only variation is in
their sizes?
Or is there a chance that out-of-order initialization of root message
members might end up scrambling these orders?
Best regards,
Jun
--
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
Visit this group at https://groups.google.com/group/capnproto.

[Junhyun Shim]

Thanks! That's all I needed to hear.
I should add that to the document and add 1-pass scan over the output
segments to compare with allocated segments.
Thanks for clarifying.

Best regards,
Jun

Post by 'Kenton Varda' via Cap'n Proto
Hi Junhyun,
I think that, at present, the only thing that would break your assumptions
is Orphanage::referenceExternalData(). You could, of course, document that
your MessageBuilder does not permit referencing external data.
Other than that, I think your assumptions currently hold -- but I don't
know if I'd be comfortable guaranteeing them. It's better if you can look
at what getSegmentForOutput() returns and handle any discrepancies between
that and what you were expecting.
-Kenton

Post by Junhyun Shim
Hi,
I'm currently writing a custom impl. of MessageBuilder (with overridden
allocateSegment virtual method that produces moveable, shallow-cloneable
buffers),
that, after fleshing out the capnproto message as a whole, produces an
internal message object backed by a static array of those buffers for I/O.
As you might have noticed, this design builds on the assumption that the
number of segments produced by getSegmentsForOutput()
does not exceed the number of calls made to allocateSegment() while
building the message.
Is this a safe guarantee? Can I even go on to assume that the base
pointers produced by getSegmentsForOutput()
are exactly the same as allocated segments and the only variation is in
their sizes?
Or is there a chance that out-of-order initialization of root message
members might end up scrambling these orders?
Best regards,
Jun
--
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
Visit this group at https://groups.google.com/group/capnproto.