Re: eventio API

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?

Good point. Will clarify this.

yes (reads no)

no

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

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

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.

For reads, only one is allowed at a time. (will clarify this)

> > 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.

And that is exacly what is planned.

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.

> 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.

I will clarify that.

In short:
When fully finished.
writes == all written (or error)
read == at least min_size of data available (or error).

> 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?

> 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.

The idea is that once you have queued a request on a connection, you
want that request to finish or abort the connection as a whole
(ncomm_abort).

There is however a problem in how to handle the "new" operations
(ncomm_listen, ncomm_connect, ncomm_accept). Will think those over to
try to find a better approach, but I think those will be changed to

   ncomm_listen: return a dummy handle for the listener

   ncomm_accept, ncomm_connect: return a early handle for the connection
to be. Not valid for read/write until the callback has been called.

(and yes, this also means that ncomm_accept gets the functionality of
accepting a single connection)

Many thanks for the feedback.

/Henrik
Received on Mon Feb 19 2001 - 23:47:28 MST