Re: eventio API

On Tue, 20 Feb 2001, Henrik Nordstrom wrote:

> I have not decided if no == not being called, or if no == being called
> with an error, but I am leaning towards the first (not being called).

"Not being called at all" implies that there can be only one "owner"
of the data being written or read. For example, a logical thread
cannot write headers and then (before receiving a callback) forward
the handler to a different logical thread. If the second thread
decides to abort, the first thread will never hear a callback and may
not clean up properly.

IMHO, every [accepted] ncomm_io() call must result in a callback. This
approach reduces guess work and allows for a more flexible design on
the user side.

Both approaches will "work", but I would recommend documenting and
explaining the basic principle (one "owner" versus possible multiple
"owners") in the preamble.
 
> Currently the idea is that the order needs to be presered. Not sure how
> Win32 handles networking I/O, but I doubt it can do out-of-order writes
> while preserving the data order.

Please note that we were talking about notifications (callbacks)
order, not I/O order. In WinSock2, the I/O order is preserved, the
notification order is not. We do not have to follow that model, of
course, must we must clearly document what model a wrapper implements.
 
> I did intentionally not include the specification of IOBUF in this
> chapter. It will be described separately. From my previous message in
> the thread, introducing the I/O buffer concept amongs a number of other
> requirements:
>
> * I/O data MUST be refecence counted buffers
>
> The reference counted buffers needs to keep
>
> * reference count
> * amount of data currently in the buffer
> * actual (allocated) size of the buffer
> * the actual buffer itself
>
> Sort of similar to the MemBuf concept, but with a reference count.

I would remove "size" and "offset" parameters from the function calls
and callbacks then. 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. You may want to introduce a concept of IOBuf "range"
(IOBufRange is for IOBuf as Substring is for a String -- a descriptor
of a range within some buffer):

        class IOBufRange {
                ...
                size offset; // start of the range
                size length; // range length
                IOBuf *buf; // actual buffer
        };

Usually, these simple structures need not to be alloc()ated and can
reside on stack; they are practically as efficient as passing isolated
parameters but less error prone and more convenient.

I think only min_size parameter should be left (if we want to support
it at all!). If min_size parameter is to be supported, there should be
an interface to query how much data was received so far. For example,
if I am waiting for at least 4KB of data and has been waiting for
1hour, I would probably want to abort. However, to print a useful
error message, I would like to know if any data was received so far. I
do not think we can safely assume that all ncomm_ implementations will
use supplied buffers to store incoming data (until it is time for a
callback). If that is the assumption, it must be documented.

> > Note that "one I/O per ncomm_io() call" interface is less efficient
> > because the library will have to wait for user action even if it can
> > proceed on its own.
>
> I do not quite follow what you are saying here. Can you please expand a
> little?

"one I/O per ncomm_io() call" interface means that ncomm library
cannot continue doing IOs after sending a callback until the user
calls ncomm_io again. As far as I can see, you are not going to follow
this less efficient model. That is, you want to allow ncomm_ routines
to proceed with more IOs as long as they have buffers available.

Thanks,
 
Alex.
Received on Tue Feb 20 2001 - 09:02:21 MST