Re: eventio API

Alex Rousskov wrote:

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

Partly agreed, but at the same time, receiving callback while shutting
something down a connection is also quite error prone.

My view is that connection management should be managed "centrally" by
the caller. I don't view it as acceptable that one logical thread
cancels a connection currently in use by another logical thread.

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

Now documented to preserve order of the callbacks as well as data.

> I would remove "size" and "offset" parameters from the function calls
> and callbacks then.

In almost all calls to ncomm_read/ncomm_write the size (and offset for
write) will not be specified.

The callbacks will surely have them, as this is required for quite many
things.

I think I will keep them separate for the time being, but might switch
some (callbacks and ncomm_write) to use the range concept..

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

> I think only min_size parameter should be left (if we want to support
> it at all!).

I'll probably remove it, and leave it to the caller to enforce a min
size.

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

I am allowing multiple queued write operations, but only one read. For
reads it is assumed the TCP receive buffer will give us the slack needed
to maintain performance.

Hmm.. maybe there is need for a long-term read operation, which calls
the callback with new IOBUF handles as the data arrives until the
specified amount of data has been received.

void
ncomm_read_stream(filehandle *fh, size_t size, COMMIOCB *callback, void
*cbdata)

  Reads "size" amount of data from the stream, and sends it to the
  callback in form of IOBUF:s as the data arrives.

  IOBUF:ers will be created as required.

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

/Henrik
Received on Tue Feb 20 2001 - 15:45:51 MST