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
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
