libeio/eio.pod

=head1 NAME

libeio - truly asynchronous POSIX I/O

=head1 SYNOPSIS

  #include <eio.h>

=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<http://pod.tst.eu/http://cvs.schmorp.de/libeio/eio.pod>.

Note that this library is a by-product of the C<IO::AIO> perl
module, and many of the subtler points regarding requets lifetime
and so on are only documented in its documentation at the
moment: L<http://pod.tst.eu/http://cvs.schmorp.de/IO-AIO/AIO.pm>.

=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<read> and C<write>, but also C<open>, C<stat>, C<unlink> and
similar functions, as well as less rarely ones such as C<mknod>, C<futime>
or C<readlink>.

It also offers wrappers around C<sendfile> (Solaris, Linux, HP-UX and
FreeBSD, with emulation on other platforms) and C<readahead> (Linux, with
emulation elsewhere>).

The goal is to enable 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<readdir>.

=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<eio_tstamp>, but it is guarenteed to be of type C<double> (or
better), so you can freely use C<double> yourself.

Unlike the name component C<stamp> might indicate, it is also used for
time differences throughout libeio.

=head2 FORK SUPPORT

Calling C<fork ()> 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<errno> 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<want_poll> callback is invoked whenever libeio wants attention (i.e.
it wants to be polled by calling C<eio_poll>). 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<you must
not call any libeio functions inside this callback>. That includes
C<eio_poll>. What you should do is notify some other thread, or wake up
your event loop, and then call C<eio_poll>.

=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<want_poll>. To put it differently, C<want_poll> and
C<done_poll> are invoked in pairs: after C<want_poll> you have to call
C<eio_poll ()> until either C<eio_poll> indicates that everything has been
handled or C<done_poll> has been called, which signals the same.

Note that C<eio_poll> might return after C<done_poll> and C<want_poll>
have been called again, so watch out for races in your code.

As with C<want_poll>, this callback is called while lcoks are being held,
so you I<must not call any libeio functions form within this callback>.

=item int eio_poll ()

This function has to be called whenever there are pending requests that
need finishing. You usually call this after C<want_poll> 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<eio_poll ()>
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<ev_async> watcher: the
C<want_poll> callback would invoke C<ev_async_send> to wake up the event
loop. Inside the callback set for the watcher, one would call C<eio_poll
()> (followed by C<ev_async_send> again if C<eio_poll> 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<eio_poll>. 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<want_poll> you would write a single byte, in C<done_poll> you would try
to read that byte, and in the callback for the read end, you would call
C<eio_poll>. 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<done_poll>).

=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<eio_poll ()> to return after it has detected that it was
running for C<nsecond> 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<eio_poll> is up to one callback invocation longer then this
interval.

b) this is implemented by calling C<gettimeofday> 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<nreqs> is non-zero, then C<eio_poll> will not handle more than
C<nreqs> requests per invocation. This is a less costly way to limit the
amount of work done by C<eio_poll> 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<nthreads> 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<eio_poll>).

=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.

Note that, when including C<libeio.m4>, you are responsible for defining
the compilation environment (C<_LARGEFILE_SOURCE>, C<_GNU_SOURCE> etc.).

If you need to know how, check the C<IO::AIO> perl module, which does
exactly that.


=head1 COMPILETIME CONFIGURATION

These symbols, if used, must be defined when compiling F<eio.c>.

=over 4

=item EIO_STACKSIZE

This symbol governs the stack size for each eio thread. Libeio itself
was written to use very little stackspace, but when using C<EIO_CUSTOM>
requests, you might want to increase this.

If this symbol is undefined (the default) then libeio will use its default
stack size (C<sizeof (long) * 4096> currently).  If it is defined, but
C<0>, then the default operating system stack size will be used. In all
other cases, the value must be an expression that evaluates to the desired
stack size.

=back


=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<fork ()> 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<double> must hold a time value in seconds with enough accuracy

The type C<double> 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 <libeio@schmorp.de>.

Revision:	1.5
Committed:	Sun Nov 29 15:53:48 2009 UTC (14 years, 5 months ago) by root
Branch:	MAIN
CVS Tags:	rel-3_71, rel-3_7, rel-3_6, rel-3_5, rel-3_4, rel-3_9, rel-3_8, rel-3_65
Changes since 1.4:	+1 -1 lines
Log Message:	Sergey Shepelev <temotor@gmail.com>
#	User	Rev	Content
1	root	1.1	=head1 NAME
2
3			libeio - truly asynchronous POSIX I/O
4
5			=head1 SYNOPSIS
6
7			#include <eio.h>
8
9			=head1 DESCRIPTION
10
11			The newest version of this document is also available as an html-formatted
12			web page you might find easier to navigate when reading it for the first
13			time: L<http://pod.tst.eu/http://cvs.schmorp.de/libeio/eio.pod>.
14
15			Note that this library is a by-product of the C<IO::AIO> perl
16			module, and many of the subtler points regarding requets lifetime
17			and so on are only documented in its documentation at the
18			moment: L<http://pod.tst.eu/http://cvs.schmorp.de/IO-AIO/AIO.pm>.
19
20			=head2 FEATURES
21
22			This library provides fully asynchronous versions of most POSIX functions
23			dealign with I/O. Unlike most asynchronous libraries, this not only
24			includes C<read> and C<write>, but also C<open>, C<stat>, C<unlink> and
25			similar functions, as well as less rarely ones such as C<mknod>, C<futime>
26			or C<readlink>.
27
28			It also offers wrappers around C<sendfile> (Solaris, Linux, HP-UX and
29			FreeBSD, with emulation on other platforms) and C<readahead> (Linux, with
30			emulation elsewhere>).
31
32	root	1.5	The goal is to enable you to write fully non-blocking programs. For
33	root	1.1	example, in a game server, you would not want to freeze for a few seconds
34			just because the server is running a backup and you happen to call
35			C<readdir>.
36
37			=head2 TIME REPRESENTATION
38
39			Libeio represents time as a single floating point number, representing the
40			(fractional) number of seconds since the (POSIX) epoch (somewhere near
41			the beginning of 1970, details are complicated, don't ask). This type is
42			called C<eio_tstamp>, but it is guarenteed to be of type C<double> (or
43			better), so you can freely use C<double> yourself.
44
45			Unlike the name component C<stamp> might indicate, it is also used for
46			time differences throughout libeio.
47
48			=head2 FORK SUPPORT
49
50			Calling C<fork ()> is fully supported by this module. It is implemented in these steps:
51
52			1. wait till all requests in "execute" state have been handled
53			(basically requests that are already handed over to the kernel).
54			2. fork
55			3. in the parent, continue business as usual, done
56			4. in the child, destroy all ready and pending requests and free the
57			memory used by the worker threads. This gives you a fully empty
58			libeio queue.
59
60			=head1 INITIALISATION/INTEGRATION
61
62			Before you can call any eio functions you first have to initialise the
63			library. The library integrates into any event loop, but can also be used
64			without one, including in polling mode.
65
66			You have to provide the necessary glue yourself, however.
67
68			=over 4
69
70			=item int eio_init (void (want_poll)(void), void (done_poll)(void))
71
72			This function initialises the library. On success it returns C<0>, on
73			failure it returns C<-1> and sets C<errno> appropriately.
74
75			It accepts two function pointers specifying callbacks as argument, both of
76			which can be C<0>, in which case the callback isn't called.
77
78			=item want_poll callback
79
80			The C<want_poll> callback is invoked whenever libeio wants attention (i.e.
81			it wants to be polled by calling C<eio_poll>). It is "edge-triggered",
82			that is, it will only be called once when eio wants attention, until all
83			pending requests have been handled.
84
85			This callback is called while locks are being held, so I<you must
86			not call any libeio functions inside this callback>. That includes
87			C<eio_poll>. What you should do is notify some other thread, or wake up
88			your event loop, and then call C<eio_poll>.
89
90			=item done_poll callback
91
92			This callback is invoked when libeio detects that all pending requests
93			have been handled. It is "edge-triggered", that is, it will only be
94			called once after C<want_poll>. To put it differently, C<want_poll> and
95			C<done_poll> are invoked in pairs: after C<want_poll> you have to call
96			C<eio_poll ()> until either C<eio_poll> indicates that everything has been
97			handled or C<done_poll> has been called, which signals the same.
98
99			Note that C<eio_poll> might return after C<done_poll> and C<want_poll>
100			have been called again, so watch out for races in your code.
101
102			As with C<want_poll>, this callback is called while lcoks are being held,
103			so you I<must not call any libeio functions form within this callback>.
104
105			=item int eio_poll ()
106
107			This function has to be called whenever there are pending requests that
108			need finishing. You usually call this after C<want_poll> has indicated
109			that you should do so, but you can also call this function regularly to
110			poll for new results.
111
112			If any request invocation returns a non-zero value, then C<eio_poll ()>
113			immediately returns with that value as return value.
114
115			Otherwise, if all requests could be handled, it returns C<0>. If for some
116			reason not all requests have been handled, i.e. some are still pending, it
117			returns C<-1>.
118
119			=back
120
121			For libev, you would typically use an C<ev_async> watcher: the
122			C<want_poll> callback would invoke C<ev_async_send> to wake up the event
123			loop. Inside the callback set for the watcher, one would call C<eio_poll
124			()> (followed by C<ev_async_send> again if C<eio_poll> indicates that not
125			all requests have been handled yet). The race is taken care of because
126			libev resets/rearms the async watcher before calling your callback,
127			and therefore, before calling C<eio_poll>. This might result in (some)
128			spurious wake-ups, but is generally harmless.
129
130			For most other event loops, you would typically use a pipe - the event
131			loop should be told to wait for read readyness on the read end. In
132			C<want_poll> you would write a single byte, in C<done_poll> you would try
133			to read that byte, and in the callback for the read end, you would call
134			C<eio_poll>. The race is avoided here because the event loop should invoke
135			your callback again and again until the byte has been read (as the pipe
136			read callback does not read it, only C<done_poll>).
137
138			=head2 CONFIGURATION
139
140			The functions in this section can sometimes be useful, but the default
141			configuration will do in most case, so you should skip this section on
142			first reading.
143
144			=over 4
145
146			=item eio_set_max_poll_time (eio_tstamp nseconds)
147
148			This causes C<eio_poll ()> to return after it has detected that it was
149			running for C<nsecond> seconds or longer (this number can be fractional).
150
151			This can be used to limit the amount of time spent handling eio requests,
152			for example, in interactive programs, you might want to limit this time to
153			C<0.01> seconds or so.
154
155			Note that:
156
157			a) libeio doesn't know how long your request callbacks take, so the time
158			spent in C<eio_poll> is up to one callback invocation longer then this
159			interval.
160
161			b) this is implemented by calling C<gettimeofday> after each request,
162			which can be costly.
163
164			c) at least one request will be handled.
165
166			=item eio_set_max_poll_reqs (unsigned int nreqs)
167
168			When C<nreqs> is non-zero, then C<eio_poll> will not handle more than
169			C<nreqs> requests per invocation. This is a less costly way to limit the
170			amount of work done by C<eio_poll> then setting a time limit.
171
172			If you know your callbacks are generally fast, you could use this to
173			encourage interactiveness in your programs by setting it to C<10>, C<100>
174			or even C<1000>.
175
176			=item eio_set_min_parallel (unsigned int nthreads)
177
178			Make sure libeio can handle at least this many requests in parallel. It
179			might be able handle more.
180
181			=item eio_set_max_parallel (unsigned int nthreads)
182
183			Set the maximum number of threads that libeio will spawn.
184
185			=item eio_set_max_idle (unsigned int nthreads)
186
187			Libeio uses threads internally to handle most requests, and will start and stop threads on demand.
188
189			This call can be used to limit the number of idle threads (threads without
190			work to do): libeio will keep some threads idle in preperation for more
191			requests, but never longer than C<nthreads> threads.
192
193			In addition to this, libeio will also stop threads when they are idle for
194			a few seconds, regardless of this setting.
195
196			=item unsigned int eio_nthreads ()
197
198			Return the number of worker threads currently running.
199
200			=item unsigned int eio_nreqs ()
201
202			Return the number of requests currently handled by libeio. This is the
203			total number of requests that have been submitted to libeio, but not yet
204			destroyed.
205
206			=item unsigned int eio_nready ()
207
208			Returns the number of ready requests, i.e. requests that have been
209			submitted but have not yet entered the execution phase.
210
211			=item unsigned int eio_npending ()
212
213			Returns the number of pending requests, i.e. requests that have been
214			executed and have results, but have not been finished yet by a call to
215			C<eio_poll>).
216
217			=back
218
219
220			=head1 ANATOMY OF AN EIO REQUEST
221
222			#TODO
223
224
225			=head1 HIGH LEVEL REQUEST API
226
227			#TODO
228
229			=back
230
231
232			=head1 LOW LEVEL REQUEST API
233
234			#TODO
235
236			=head1 EMBEDDING
237
238			Libeio can be embedded directly into programs. This functionality is not
239			documented and not (yet) officially supported.
240
241	root	1.3	Note that, when including C<libeio.m4>, you are responsible for defining
242			the compilation environment (C<_LARGEFILE_SOURCE>, C<_GNU_SOURCE> etc.).
243
244	root	1.2	If you need to know how, check the C<IO::AIO> perl module, which does
245	root	1.1	exactly that.
246
247
248	root	1.4	=head1 COMPILETIME CONFIGURATION
249
250			These symbols, if used, must be defined when compiling F<eio.c>.
251
252			=over 4
253
254			=item EIO_STACKSIZE
255
256			This symbol governs the stack size for each eio thread. Libeio itself
257			was written to use very little stackspace, but when using C<EIO_CUSTOM>
258			requests, you might want to increase this.
259
260			If this symbol is undefined (the default) then libeio will use its default
261			stack size (C<sizeof (long) * 4096> currently). If it is defined, but
262			C<0>, then the default operating system stack size will be used. In all
263			other cases, the value must be an expression that evaluates to the desired
264			stack size.
265
266			=back
267
268
269	root	1.1	=head1 PORTABILITY REQUIREMENTS
270
271			In addition to a working ISO-C implementation, libeio relies on a few
272			additional extensions:
273
274			=over 4
275
276			=item POSIX threads
277
278			To be portable, this module uses threads, specifically, the POSIX threads
279			library must be available (and working, which partially excludes many xBSD
280			systems, where C<fork ()> is buggy).
281
282			=item POSIX-compatible filesystem API
283
284			This is actually a harder portability requirement: The libeio API is quite
285			demanding regarding POSIX API calls (symlinks, user/group management
286			etc.).
287
288			=item C<double> must hold a time value in seconds with enough accuracy
289
290			The type C<double> is used to represent timestamps. It is required to
291			have at least 51 bits of mantissa (and 9 bits of exponent), which is good
292			enough for at least into the year 4000. This requirement is fulfilled by
293			implementations implementing IEEE 754 (basically all existing ones).
294
295			=back
296
297			If you know of other additional requirements drop me a note.
298
299
300			=head1 AUTHOR
301
302			Marc Lehmann <libeio@schmorp.de>.
303