eventio API

Have slept on this and came up with the following:

* A cbdata type should be used instead of a unix FD. This struct
contains all the gory details about current handlers, arguments, pending
I/O and such.

* The global table only contains references to the current cbdata
registered struct for a UNIX fd (i.e. lookup from UNIX fd to
"filehandle" struct)

* User supplied callback data MUST be cbdata registered

* 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

Reference count starts at 1 when the buffer is allocated, and the buffer
is freed when the reference count reaches zero.

Why a cbdata type is required for the filehandle:
a) if there is pending callbacks when a handle is closed
b) to 100% be able to detect if the caller reuses a closed handle,
either directly or indirectly via a pending callback.
c) fresh start for each new handle

/Henrik

Henrik Nordstrom wrote:
>
> My goal is that this should be handled by cbdata checks, but I have not
> yet found a foolprof way of doing that (at least not until all data has
> reference counters)
>
> /Henrik
>
> adri wrote:
>
> > * add some REAL tasty logic in ncomm_close(), which is called by
> > comm_close() when a fd goes away. Right now, I'm walking the callback
> > list and completing any pending callbacks. If one of the callbacks is
> > a pending write, we close it with COMM_ERR_CLOSING so the routine
> > knows we're going away. The logic is *TASTY* here, and its not going
> > to scale well because we are searching the pending request list, but
> > again this code will only exist whilst small debugging is done, and then
> > it'll come out and be replaced with something a little nicer.
Received on Sat Feb 17 2001 - 00:19:34 MST