Re: eventio API

On Sat, Feb 17, 2001, Henrik Nordstrom wrote:
> 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

I kind of agree but its starting to get a little complicated now.
The other issue with the eventio code is that we aren't working with
a 1 client -- 1 server setup like the modio branch, we're working
with many clients - 1 server setup which could interfere with things.

Perhaps we want to look at finishing the modio branch to a point
where the eventio code will fit in better? Once I abstract the request/reply
objects a little further the IO requirements for each will be a lot
clearer imho.

adrian

-- 
Adrian Chadd			"Romance novel?"
<adrian@creative.net.au>	 "Girl Porn."
				    - http://www.sinfest.net/d/20010202.html