Re: eventio API

On Mon, 19 Feb 2001, Alex Rousskov wrote:

> You may want to document that ncomm_abort() does/does-not call
> ncomm_close().
>
> Will ncomm_abort() cause all/any callbacks to be called?
>
> Will ncomm_close() cause all/any callbacks to be called?
>
> To handle W2K "overlapping I/Os", you need to specify that write()
> callbacks may not be called in the order the write buffers were
> supplied. Likewise on the read() side. If you expect the wrappers to
> ensure the notification order, that has to be documented (and you may
> have problems with notifying the user that buf#2 was filled but buf#1
> callback never came).
>
> > buf might be specified as NULL in which case a IOBUF will be
> > allocated to keep the data read from the network.
>
> In general, you would then need to provide a method to allocate the
> buffer. At the very least, please document how the callback can find
> out whether the buffer was allocated and needs to be freed. It would
> be "bad" to require the ncomm user to pass that information from the
> ncomm_io() caller to the callback somehow.
>
> > if size is 0 then all data in the buffer will be written.
>
> Sounds like an unnatural and error-prone hack. Why not require that at
> most "size" bytes will be written (naturally)? Am I missing something?
>
> In general, it may be a good idea and appropriate timing to move all
> size specifications into the IOBUF structure itself rather than carry
> them along all the time. IMHO, having "self contained" IOBufs (and
> IOBufRanges, if needed) is very convenient and less error-prone.

Also, if I queue a write request for 2KB and 1KB gets written, the
specs say I will receive a callback ("Called when an I/O operation has
finished"). Do I then need to re-queue the request for the rest of the
buffer to be written? I think the answer is "no" due to the "the
requests will be processed in the order requested" requirement, but
this needs to be documented.

Same for reading. Do I need to call read() again even if the supplied
buffer still has space after the first read?

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. On the other hand, if I/O requests are "sticky",
how do I terminate pending ones without calling abort()? This needs to
be explained or at least documented.

Alex.
Received on Mon Feb 19 2001 - 17:06:00 MST