Alex Rousskov wrote:
> IoBuf could have the "size" field (only) which will be updated by the
> ncomm_read request in your example. Offset fields will not be a part
> of IoBuf, of course. The design could be similar to the classic
> "string" (IoBuf with size) versus "substring" (IoBufRange with
> offsets) design.
The reason why ncomm_write has a offset,size argument is that you might
not always want to write all data currently in the IOBUF.
The reason why the callback has offset,size is that read handlers (and
write handlers in the above case) might need to know exacly what part of
the IOBUF that the call is valid for.
> Yeah, tricky. The more smartness we put into ncomm_ calls, the harder
> it would be to control them based on external requirements such as
> bandwidth limits. An I-want-more return code from the
> ncomm_read_stream callback may be appropriate (perhaps as a parameter
> with the default value):
But then they might just as well reschedule yet another ncomm_read
operation. Due to call graphs and recursion resolution the overwhead
will for most implementations be about the same, but with a less
complicated ncomm_* implementation.. but my mind is not fully set yet. I
am perhaps considering something along that line (the functionality
already exists internally in ncomm.c, but it is not all trivial to map
it to the callbacks as well)
/Henrik
Received on Tue Feb 20 2001 - 17:01:59 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:33 MST