Re: eventio API

On Mon, 19 Feb 2001, Henrik Nordstrom wrote:

> Hi fellow Squid hackers.
>
> Attached is a suggestion for the new API to the upcoming eventdriven
> network I/O layer. Comments are welcome.
>
> The goal of this layer is to abstract most of the
> select/poll/read/write/whatever issues from the rest of the code,
> allowing the I/O to be implemented in an much more efficient manner
> using the primitives available on the platform.
>
> Note: The initial implementation will be poll() driven, but adding other
> implementations like select, /dev/poll, Win32 completetion ports (is
> this the correct term?) or whatever is only a matter of implementing
> them ;-)

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.

$0.02,

Alex.
Received on Mon Feb 19 2001 - 16:47:38 MST