From b897dac732094657aa697284f33ebbb5f2ba3bc2 Mon Sep 17 00:00:00 2001 From: root Date: Sun, 11 May 2008 13:05:10 +0000 Subject: *** empty log message *** --- eio.pod | 279 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 279 insertions(+) create mode 100644 eio.pod (limited to 'eio.pod') diff --git a/eio.pod b/eio.pod new file mode 100644 index 0000000..e21df31 --- /dev/null +++ b/eio.pod @@ -0,0 +1,279 @@ +=head1 NAME + +libeio - truly asynchronous POSIX I/O + +=head1 SYNOPSIS + + #include + +=head1 DESCRIPTION + +The newest version of this document is also available as an html-formatted +web page you might find easier to navigate when reading it for the first +time: L. + +Note that this library is a by-product of the C perl +module, and many of the subtler points regarding requets lifetime +and so on are only documented in its documentation at the +moment: L. + +=head2 FEATURES + +This library provides fully asynchronous versions of most POSIX functions +dealign with I/O. Unlike most asynchronous libraries, this not only +includes C and C, but also C, C, C and +similar functions, as well as less rarely ones such as C, C +or C. + +It also offers wrappers around C (Solaris, Linux, HP-UX and +FreeBSD, with emulation on other platforms) and C (Linux, with +emulation elsewhere>). + +The goal is to enbale you to write fully non-blocking programs. For +example, in a game server, you would not want to freeze for a few seconds +just because the server is running a backup and you happen to call +C. + +=head2 TIME REPRESENTATION + +Libeio represents time as a single floating point number, representing the +(fractional) number of seconds since the (POSIX) epoch (somewhere near +the beginning of 1970, details are complicated, don't ask). This type is +called C, but it is guarenteed to be of type C (or +better), so you can freely use C yourself. + +Unlike the name component C might indicate, it is also used for +time differences throughout libeio. + +=head2 FORK SUPPORT + +Calling C is fully supported by this module. It is implemented in these steps: + + 1. wait till all requests in "execute" state have been handled + (basically requests that are already handed over to the kernel). + 2. fork + 3. in the parent, continue business as usual, done + 4. in the child, destroy all ready and pending requests and free the + memory used by the worker threads. This gives you a fully empty + libeio queue. + +=head1 INITIALISATION/INTEGRATION + +Before you can call any eio functions you first have to initialise the +library. The library integrates into any event loop, but can also be used +without one, including in polling mode. + +You have to provide the necessary glue yourself, however. + +=over 4 + +=item int eio_init (void (*want_poll)(void), void (*done_poll)(void)) + +This function initialises the library. On success it returns C<0>, on +failure it returns C<-1> and sets C appropriately. + +It accepts two function pointers specifying callbacks as argument, both of +which can be C<0>, in which case the callback isn't called. + +=item want_poll callback + +The C callback is invoked whenever libeio wants attention (i.e. +it wants to be polled by calling C). It is "edge-triggered", +that is, it will only be called once when eio wants attention, until all +pending requests have been handled. + +This callback is called while locks are being held, so I. That includes +C. What you should do is notify some other thread, or wake up +your event loop, and then call C. + +=item done_poll callback + +This callback is invoked when libeio detects that all pending requests +have been handled. It is "edge-triggered", that is, it will only be +called once after C. To put it differently, C and +C are invoked in pairs: after C you have to call +C until either C indicates that everything has been +handled or C has been called, which signals the same. + +Note that C might return after C and C +have been called again, so watch out for races in your code. + +As with C, this callback is called while lcoks are being held, +so you I. + +=item int eio_poll () + +This function has to be called whenever there are pending requests that +need finishing. You usually call this after C has indicated +that you should do so, but you can also call this function regularly to +poll for new results. + +If any request invocation returns a non-zero value, then C +immediately returns with that value as return value. + +Otherwise, if all requests could be handled, it returns C<0>. If for some +reason not all requests have been handled, i.e. some are still pending, it +returns C<-1>. + +=back + +For libev, you would typically use an C watcher: the +C callback would invoke C to wake up the event +loop. Inside the callback set for the watcher, one would call C (followed by C again if C indicates that not +all requests have been handled yet). The race is taken care of because +libev resets/rearms the async watcher before calling your callback, +and therefore, before calling C. This might result in (some) +spurious wake-ups, but is generally harmless. + +For most other event loops, you would typically use a pipe - the event +loop should be told to wait for read readyness on the read end. In +C you would write a single byte, in C you would try +to read that byte, and in the callback for the read end, you would call +C. The race is avoided here because the event loop should invoke +your callback again and again until the byte has been read (as the pipe +read callback does not read it, only C). + +=head2 CONFIGURATION + +The functions in this section can sometimes be useful, but the default +configuration will do in most case, so you should skip this section on +first reading. + +=over 4 + +=item eio_set_max_poll_time (eio_tstamp nseconds) + +This causes C to return after it has detected that it was +running for C seconds or longer (this number can be fractional). + +This can be used to limit the amount of time spent handling eio requests, +for example, in interactive programs, you might want to limit this time to +C<0.01> seconds or so. + +Note that: + +a) libeio doesn't know how long your request callbacks take, so the time +spent in C is up to one callback invocation longer then this +interval. + +b) this is implemented by calling C after each request, +which can be costly. + +c) at least one request will be handled. + +=item eio_set_max_poll_reqs (unsigned int nreqs) + +When C is non-zero, then C will not handle more than +C requests per invocation. This is a less costly way to limit the +amount of work done by C then setting a time limit. + +If you know your callbacks are generally fast, you could use this to +encourage interactiveness in your programs by setting it to C<10>, C<100> +or even C<1000>. + +=item eio_set_min_parallel (unsigned int nthreads) + +Make sure libeio can handle at least this many requests in parallel. It +might be able handle more. + +=item eio_set_max_parallel (unsigned int nthreads) + +Set the maximum number of threads that libeio will spawn. + +=item eio_set_max_idle (unsigned int nthreads) + +Libeio uses threads internally to handle most requests, and will start and stop threads on demand. + +This call can be used to limit the number of idle threads (threads without +work to do): libeio will keep some threads idle in preperation for more +requests, but never longer than C threads. + +In addition to this, libeio will also stop threads when they are idle for +a few seconds, regardless of this setting. + +=item unsigned int eio_nthreads () + +Return the number of worker threads currently running. + +=item unsigned int eio_nreqs () + +Return the number of requests currently handled by libeio. This is the +total number of requests that have been submitted to libeio, but not yet +destroyed. + +=item unsigned int eio_nready () + +Returns the number of ready requests, i.e. requests that have been +submitted but have not yet entered the execution phase. + +=item unsigned int eio_npending () + +Returns the number of pending requests, i.e. requests that have been +executed and have results, but have not been finished yet by a call to +C). + +=back + + +=head1 ANATOMY OF AN EIO REQUEST + +#TODO + + +=head1 HIGH LEVEL REQUEST API + +#TODO + +=back + + +=head1 LOW LEVEL REQUEST API + +#TODO + +=head1 EMBEDDING + +Libeio can be embedded directly into programs. This functionality is not +documented and not (yet) officially supported. + +If you ened to know how, cehck the C perl module, which does +exactly that. + + +=head1 PORTABILITY REQUIREMENTS + +In addition to a working ISO-C implementation, libeio relies on a few +additional extensions: + +=over 4 + +=item POSIX threads + +To be portable, this module uses threads, specifically, the POSIX threads +library must be available (and working, which partially excludes many xBSD +systems, where C is buggy). + +=item POSIX-compatible filesystem API + +This is actually a harder portability requirement: The libeio API is quite +demanding regarding POSIX API calls (symlinks, user/group management +etc.). + +=item C must hold a time value in seconds with enough accuracy + +The type C is used to represent timestamps. It is required to +have at least 51 bits of mantissa (and 9 bits of exponent), which is good +enough for at least into the year 4000. This requirement is fulfilled by +implementations implementing IEEE 754 (basically all existing ones). + +=back + +If you know of other additional requirements drop me a note. + + +=head1 AUTHOR + +Marc Lehmann . + -- cgit v1.2.3