How *I* would design a libevaio

[Marc Lehmann]

Since I already wrote some aio framework and sue it a lot, but miss the
ability to use it directly from C, here is how I would design it's API.

Much of the fucntionality would be similar to what the IO::AIO,perl module
uses, the C api would be similar to both the POSIX functions (just with a
continuation/callback) and libev. See IO::AIO's functions here:

      http://pod.tst.eu/http://cvs.schmorp.de/IO-AIO/AIO.pm#FUNCTIONS

Event loop ties

   It would not be tied to an event loop, not even ev. Currently IO::AIO
   offers a file descriptor the user has to poll for read, or ignore
   and call the processing hook regularly, allowing quasi-synchronous
   operation and independence of any particular event loop.

   In a new design I would offer this, but also optionally a callback,
   that clalbakc could then use ev_async for example, which is (sometimes)
   more efficient then polling a pipe. but no other event loop I know has
   something like ev_async, so offerign a file descriptor is a must.

Result Processing

   result processing would be strictly synchronous and single-threaded.
   the user would have to call a function (e.g. evaio_poll).

   There would be an option to limit the number of results processed per
   evaio_poll call, and a limit on the overall time (resulting in lots of
   gettimeofday calls).

   See the support functions in IO::AIO.

Threading

   it would use threading internally for most requests. The api would
   allow usage of overlapped I/O or aio_read/write functions internally
   (but doesn't need to be implemented thta way, so future expansion is
   possible).

   See "CONTROLLING THE NUMBER OF THREADS" in the IO::AIO documentation.

There would be one, or two ways to handle aio requests:

   1. simple posix-like wrappers, e.g.

       evaio_read (fd, offset, length, address, (callback, data))
       evaio_fstat (fd, (callback, data))
       evaio_stat (pathname, (callback, data))
       evaio_link...

      and so on. A full list of functions I found a requirement for
      low-latency programming can be found in the IO::AIO document,

   2. setup/queue primitives for special uses (which would look very much
      like ev, btw.), which require more work, but are slightly more
      flexible:

       evaio_req req;
       evaio_read_init (req, parameters);
       evaio_start (req);

Sugar

   I found some additional primitives very useful, for example, grouping
   (see IO::AIO::grp in the above url), as well as being able to cancel
   requests in a defined way.


In fact, I was close to separate the c parts of IO::AIO into a separate
library a number of times, but the demand wasn't so high (for example, the
deliantra game server which is mostly written in C++ simply calls out to
perl for all I/O operations, which certainly was fast enough so far).

Of course I also don't really have the time, thats why I wrote "how I
*would* design...", but I, too, would like to have something like that.

As for windows compatibility, of course probelms start with stuff like
evaio_stat and end at evaio_readdir. In fact, IO::AIO uses the same
thread abstratcion as the BDB perl module (thread-pool for async berkeley
db access), and while BDB works on windows, IO::AIO doesn't, as the
differences in API are too large.

The best one could do is probably return ENOSYS for almost all functions
on windows (after defining ENOSYS probably :).

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      pcg at goof.com
      -=====/_/_//_/\_,_/ /_/\_\