Re: eventio API

On Tue, 20 Feb 2001, Henrik Nordstrom wrote:

> > Those parameters should be a part of the IOBuf or
> > IOBufRange structures, IMO. It is awkward to have some of the size
> > parameters to be specified in the structure and some maintained
> > outside.
>
> A partly agree, but certainly NOT as part of the IOBUF. Other parts of
> the same IOBUF might be in use at other locations in the code. For
> example there might be one ncomm_read request adding more data to the
> IOBUF, and a couple of consumers currently processing the older data.

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.
 
> But I am unsure if this actually fits in the needs here. The
> problem being that we also needs to intentionally throttle reading
> to the speed of the recipient(s) of the read data..

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):

        want_more = false;
        ncomm_read_stream_callback(...., &want_more);
        ...

Or, as you said, just avoid the ncomm_read_stream call all together.

Alex.
Received on Tue Feb 20 2001 - 16:01:31 MST