[ViewVC] Diff of: cvs/libeio/eio.pod

Comparing libeio/eio.pod (file contents):
Revision 1.3 by root, Wed Oct 22 18:15:36 2008 UTC vs.
Revision 1.15 by root, Tue Jul 5 16:57:41 2011 UTC

…		…
11	The newest version of this document is also available as an html-formatted	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	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>.	13	time: L<http://pod.tst.eu/http://cvs.schmorp.de/libeio/eio.pod>.
14		14
15	Note that this library is a by-product of the C<IO::AIO> perl	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	16	module, and many of the subtler points regarding requests lifetime
17	and so on are only documented in its documentation at the	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>.	18	moment: L<http://pod.tst.eu/http://cvs.schmorp.de/IO-AIO/AIO.pm>.
19		19
20	=head2 FEATURES	20	=head2 FEATURES
21		21
22	This library provides fully asynchronous versions of most POSIX functions	22	This library provides fully asynchronous versions of most POSIX functions
23	dealign with I/O. Unlike most asynchronous libraries, this not only	23	dealing 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	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>	25	similar functions, as well as less rarely ones such as C<mknod>, C<futime>
26	or C<readlink>.	26	or C<readlink>.
27		27
28	It also offers wrappers around C<sendfile> (Solaris, Linux, HP-UX and	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	29	FreeBSD, with emulation on other platforms) and C<readahead> (Linux, with
30	emulation elsewhere>).	30	emulation elsewhere>).
31		31
32	The goal is to enbale you to write fully non-blocking programs. For	32	The goal is to enable you to write fully non-blocking programs. For
33	example, in a game server, you would not want to freeze for a few seconds	33	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	34	just because the server is running a backup and you happen to call
35	C<readdir>.	35	C<readdir>.
36		36
37	=head2 TIME REPRESENTATION	37	=head2 TIME REPRESENTATION
38		38
39	Libeio represents time as a single floating point number, representing the	39	Libeio represents time as a single floating point number, representing the
40	(fractional) number of seconds since the (POSIX) epoch (somewhere near	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	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	42	called C<eio_tstamp>, but it is guaranteed to be of type C<double> (or
43	better), so you can freely use C<double> yourself.	43	better), so you can freely use C<double> yourself.
44		44
45	Unlike the name component C<stamp> might indicate, it is also used for	45	Unlike the name component C<stamp> might indicate, it is also used for
46	time differences throughout libeio.	46	time differences throughout libeio.
47		47
…		…
55	3. in the parent, continue business as usual, done	55	3. in the parent, continue business as usual, done
56	4. in the child, destroy all ready and pending requests and free the	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	57	memory used by the worker threads. This gives you a fully empty
58	libeio queue.	58	libeio queue.
59		59
		60	Note, however, since libeio does use threads, thr above guarantee doesn't
		61	cover your libc, for example, malloc and other libc functions are not
		62	fork-safe, so there is very little you can do after a fork, and in fatc,
		63	the above might crash, and thus change.
		64
60	=head1 INITIALISATION/INTEGRATION	65	=head1 INITIALISATION/INTEGRATION
61		66
62	Before you can call any eio functions you first have to initialise the	67	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	68	library. The library integrates into any event loop, but can also be used
64	without one, including in polling mode.	69	without one, including in polling mode.
…		…
97	handled or C<done_poll> has been called, which signals the same.	102	handled or C<done_poll> has been called, which signals the same.
98		103
99	Note that C<eio_poll> might return after C<done_poll> and C<want_poll>	104	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.	105	have been called again, so watch out for races in your code.
101		106
102	As with C<want_poll>, this callback is called while lcoks are being held,	107	As with C<want_poll>, this callback is called while locks are being held,
103	so you I<must not call any libeio functions form within this callback>.	108	so you I<must not call any libeio functions form within this callback>.
104		109
105	=item int eio_poll ()	110	=item int eio_poll ()
106		111
107	This function has to be called whenever there are pending requests that	112	This function has to be called whenever there are pending requests that
…		…
119	=back	124	=back
120		125
121	For libev, you would typically use an C<ev_async> watcher: the	126	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	127	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	128	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	129	()>.
125	all requests have been handled yet). The race is taken care of because	130
126	libev resets/rearms the async watcher before calling your callback,	131	If C<eio_poll ()> is configured to not handle all results in one go
127	and therefore, before calling C<eio_poll>. This might result in (some)	132	(i.e. it returns C<-1>) then you should start an idle watcher that calls
128	spurious wake-ups, but is generally harmless.	133	C<eio_poll> until it returns something C<!= -1>.
		134
		135	A full-featured wrapper would look as follows (if C<eio_poll> is handling
		136	all requests, it can of course be simplified a lot by removing the idle
		137	watcher logic):
		138
		139	static struct ev_loop *loop;
		140	static ev_idle repeat_watcher;
		141	static ev_async ready_watcher;
		142
		143	/* idle watcher callback, only used when eio_poll */
		144	/* didn't handle all results in one call */
		145	static void
		146	repeat (EV_P_ ev_idle *w, int revents)
		147	{
		148	if (eio_poll () != -1)
		149	ev_idle_stop (EV_A_ w);
		150	}
		151
		152	/* eio has some results, process them */
		153	static void
		154	ready (EV_P_ ev_async *w, int revents)
		155	{
		156	if (eio_poll () == -1)
		157	ev_idle_start (EV_A_ &repeat_watcher);
		158	}
		159
		160	/* wake up the event loop */
		161	static void
		162	want_poll (void)
		163	{
		164	ev_async_send (loop, &ready_watcher)
		165	}
		166
		167	void
		168	my_init_eio ()
		169	{
		170	loop = EV_DEFAULT;
		171
		172	ev_idle_init (&repeat_watcher, repeat);
		173	ev_async_init (&ready_watcher, ready);
		174	ev_async_start (loop &watcher);
		175
		176	eio_init (want_poll, 0);
		177	}
129		178
130	For most other event loops, you would typically use a pipe - the event	179	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	180	loop should be told to wait for read readiness on the read end. In
132	C<want_poll> you would write a single byte, in C<done_poll> you would try	181	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	182	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	183	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	184	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>).	185	read callback does not read it, only C<done_poll>).
137		186
		187
		188	=head1 HIGH LEVEL REQUEST API
		189
		190	Libeio has both a high-level API, which consists of calling a request
		191	function with a callback to be called on completion, and a low-level API
		192	where you fill out request structures and submit them.
		193
		194	This section describes the high-level API.
		195
		196	=head2 REQUEST SUBMISSION AND RESULT PROCESSING
		197
		198	You submit a request by calling the relevant C<eio_TYPE> function with the
		199	required parameters, a callback of type C<int (eio_cb)(eio_req req)>
		200	(called C<eio_cb> below) and a freely usable C<void *data> argument.
		201
		202	The return value will either be 0, in case something went really wrong
		203	(which can basically only happen on very fatal errors, such as C<malloc>
		204	returning 0, which is rather unlikely), or a pointer to the newly-created
		205	and submitted C<eio_req *>.
		206
		207	The callback will be called with an C<eio_req *> which contains the
		208	results of the request. The members you can access inside that structure
		209	vary from request to request, except for:
		210
		211	=over 4
		212
		213	=item C<ssize_t result>
		214
		215	This contains the result value from the call (usually the same as the
		216	syscall of the same name).
		217
		218	=item C<int errorno>
		219
		220	This contains the value of C<errno> after the call.
		221
		222	=item C<void *data>
		223
		224	The C<void *data> member simply stores the value of the C<data> argument.
		225
		226	=back
		227
		228	The return value of the callback is normally C<0>, which tells libeio to
		229	continue normally. If a callback returns a nonzero value, libeio will
		230	stop processing results (in C<eio_poll>) and will return the value to its
		231	caller.
		232
		233	Memory areas passed to libeio must stay valid as long as a request
		234	executes, with the exception of paths, which are being copied
		235	internally. Any memory libeio itself allocates will be freed after the
		236	finish callback has been called. If you want to manage all memory passed
		237	to libeio yourself you can use the low-level API.
		238
		239	For example, to open a file, you could do this:
		240
		241	static int
		242	file_open_done (eio_req *req)
		243	{
		244	if (req->result < 0)
		245	{
		246	/* open() returned -1 */
		247	errno = req->errorno;
		248	perror ("open");
		249	}
		250	else
		251	{
		252	int fd = req->result;
		253	/* now we have the new fd in fd */
		254	}
		255
		256	return 0;
		257	}
		258
		259	/* the first three arguments are passed to open(2) */
		260	/* the remaining are priority, callback and data */
		261	if (!eio_open ("/etc/passwd", O_RDONLY, 0, 0, file_open_done, 0))
		262	abort (); /* something ent wrong, we will all die!!! */
		263
		264	Note that you additionally need to call C<eio_poll> when the C<want_cb>
		265	indicates that requests are ready to be processed.
		266
		267	=head2 AVAILABLE REQUESTS
		268
		269	The following request functions are available. I<All> of them return the
		270	C<eio_req *> on success and C<0> on failure, and I<all> of them have the
		271	same three trailing arguments: C<pri>, C<cb> and C<data>. The C<cb> is
		272	mandatory, but in most cases, you pass in C<0> as C<pri> and C<0> or some
		273	custom data value as C<data>.
		274
		275	=head3 POSIX API WRAPPERS
		276
		277	These requests simply wrap the POSIX call of the same name, with the same
		278	arguments. If a function is not implemented by the OS and cannot be emulated
		279	in some way, then all of these return C<-1> and set C<errorno> to C<ENOSYS>.
		280
		281	=over 4
		282
		283	=item eio_open (const char path, int flags, mode_t mode, int pri, eio_cb cb, void data)
		284
		285	=item eio_truncate (const char path, off_t offset, int pri, eio_cb cb, void data)
		286
		287	=item eio_chown (const char path, uid_t uid, gid_t gid, int pri, eio_cb cb, void data)
		288
		289	=item eio_chmod (const char path, mode_t mode, int pri, eio_cb cb, void data)
		290
		291	=item eio_mkdir (const char path, mode_t mode, int pri, eio_cb cb, void data)
		292
		293	=item eio_rmdir (const char path, int pri, eio_cb cb, void data)
		294
		295	=item eio_unlink (const char path, int pri, eio_cb cb, void data)
		296
		297	=item eio_utime (const char path, eio_tstamp atime, eio_tstamp mtime, int pri, eio_cb cb, void data)
		298
		299	=item eio_mknod (const char path, mode_t mode, dev_t dev, int pri, eio_cb cb, void data)
		300
		301	=item eio_link (const char path, const char new_path, int pri, eio_cb cb, void *data)
		302
		303	=item eio_symlink (const char path, const char new_path, int pri, eio_cb cb, void *data)
		304
		305	=item eio_rename (const char path, const char new_path, int pri, eio_cb cb, void *data)
		306
		307	=item eio_mlock (void addr, size_t length, int pri, eio_cb cb, void data)
		308
		309	=item eio_close (int fd, int pri, eio_cb cb, void *data)
		310
		311	=item eio_sync (int pri, eio_cb cb, void *data)
		312
		313	=item eio_fsync (int fd, int pri, eio_cb cb, void *data)
		314
		315	=item eio_fdatasync (int fd, int pri, eio_cb cb, void *data)
		316
		317	=item eio_futime (int fd, eio_tstamp atime, eio_tstamp mtime, int pri, eio_cb cb, void *data)
		318
		319	=item eio_ftruncate (int fd, off_t offset, int pri, eio_cb cb, void *data)
		320
		321	=item eio_fchmod (int fd, mode_t mode, int pri, eio_cb cb, void *data)
		322
		323	=item eio_fchown (int fd, uid_t uid, gid_t gid, int pri, eio_cb cb, void *data)
		324
		325	=item eio_dup2 (int fd, int fd2, int pri, eio_cb cb, void *data)
		326
		327	These have the same semantics as the syscall of the same name, their
		328	return value is available as C<< req->result >> later.
		329
		330	=item eio_read (int fd, void buf, size_t length, off_t offset, int pri, eio_cb cb, void data)
		331
		332	=item eio_write (int fd, void buf, size_t length, off_t offset, int pri, eio_cb cb, void data)
		333
		334	These two requests are called C<read> and C<write>, but actually wrap
		335	C<pread> and C<pwrite>. On systems that lack these calls (such as cygwin),
		336	libeio uses lseek/read_or_write/lseek and a mutex to serialise the
		337	requests, so all these requests run serially and do not disturb each
		338	other. However, they still disturb the file offset while they run, so it's
		339	not safe to call these functions concurrently with non-libeio functions on
		340	the same fd on these systems.
		341
		342	Not surprisingly, pread and pwrite are not thread-safe on Darwin (OS/X),
		343	so it is advised not to submit multiple requests on the same fd on this
		344	horrible pile of garbage.
		345
		346	=item eio_mlockall (int flags, int pri, eio_cb cb, void *data)
		347
		348	Like C<mlockall>, but the flag value constants are called
		349	C<EIO_MCL_CURRENT> and C<EIO_MCL_FUTURE>.
		350
		351	=item eio_msync (void addr, size_t length, int flags, int pri, eio_cb cb, void data)
		352
		353	Just like msync, except that the flag values are called C<EIO_MS_ASYNC>,
		354	C<EIO_MS_INVALIDATE> and C<EIO_MS_SYNC>.
		355
		356	=item eio_readlink (const char path, int pri, eio_cb cb, void data)
		357
		358	If successful, the path read by C<readlink(2)> can be accessed via C<<
		359	req->ptr2 >> and is I<NOT> null-terminated, with the length specified as
		360	C<< req->result >>.
		361
		362	if (req->result >= 0)
		363	{
		364	char target = strndup ((char )req->ptr2, req->result);
		365
		366	free (target);
		367	}
		368
		369	=item eio_realpath (const char path, int pri, eio_cb cb, void data)
		370
		371	Similar to the realpath libc function, but unlike that one, result is
		372	C<-1> on failure and the length of the returned path in C<ptr2> (which is
		373	not 0-terminated) - this is similar to readlink.
		374
		375	=item eio_stat (const char path, int pri, eio_cb cb, void data)
		376
		377	=item eio_lstat (const char path, int pri, eio_cb cb, void data)
		378
		379	=item eio_fstat (int fd, int pri, eio_cb cb, void *data)
		380
		381	Stats a file - if C<< req->result >> indicates success, then you can
		382	access the C<struct stat>-like structure via C<< req->ptr2 >>:
		383
		384	EIO_STRUCT_STAT statdata = (EIO_STRUCT_STAT )req->ptr2;
		385
		386	=item eio_statvfs (const char path, int pri, eio_cb cb, void data)
		387
		388	=item eio_fstatvfs (int fd, int pri, eio_cb cb, void *data)
		389
		390	Stats a filesystem - if C<< req->result >> indicates success, then you can
		391	access the C<struct statvfs>-like structure via C<< req->ptr2 >>:
		392
		393	EIO_STRUCT_STATVFS statdata = (EIO_STRUCT_STATVFS )req->ptr2;
		394
		395	=back
		396
		397	=head3 READING DIRECTORIES
		398
		399	Reading directories sounds simple, but can be rather demanding, especially
		400	if you want to do stuff such as traversing a diretcory hierarchy or
		401	processing all files in a directory. Libeio can assist thess complex tasks
		402	with it's C<eio_readdir> call.
		403
		404	=over 4
		405
		406	=item eio_readdir (const char path, int flags, int pri, eio_cb cb, void data)
		407
		408	This is a very complex call. It basically reads through a whole directory
		409	(via the C<opendir>, C<readdir> and C<closedir> calls) and returns either
		410	the names or an array of C<struct eio_dirent>, depending on the C<flags>
		411	argument.
		412
		413	The C<< req->result >> indicates either the number of files found, or
		414	C<-1> on error. On success, null-terminated names can be found as C<< req->ptr2 >>,
		415	and C<struct eio_dirents>, if requested by C<flags>, can be found via C<<
		416	req->ptr1 >>.
		417
		418	Here is an example that prints all the names:
		419
		420	int i;
		421	char names = (char )req->ptr2;
		422
		423	for (i = 0; i < req->result; ++i)
		424	{
		425	printf ("name #%d: %s\n", i, names);
		426
		427	/* move to next name */
		428	names += strlen (names) + 1;
		429	}
		430
		431	Pseudo-entries such as F<.> and F<..> are never returned by C<eio_readdir>.
		432
		433	C<flags> can be any combination of:
		434
		435	=over 4
		436
		437	=item EIO_READDIR_DENTS
		438
		439	If this flag is specified, then, in addition to the names in C<ptr2>,
		440	also an array of C<struct eio_dirent> is returned, in C<ptr1>. A C<struct
		441	eio_dirent> looks like this:
		442
		443	struct eio_dirent
		444	{
		445	int nameofs; /* offset of null-terminated name string in (char )req->ptr2 /
		446	unsigned short namelen; /* size of filename without trailing 0 */
		447	unsigned char type; /* one of EIO_DT_* */
		448	signed char score; /* internal use */
		449	ino_t inode; /* the inode number, if available, otherwise unspecified */
		450	};
		451
		452	The only members you normally would access are C<nameofs>, which is the
		453	byte-offset from C<ptr2> to the start of the name, C<namelen> and C<type>.
		454
		455	C<type> can be one of:
		456
		457	C<EIO_DT_UNKNOWN> - if the type is not known (very common) and you have to C<stat>
		458	the name yourself if you need to know,
		459	one of the "standard" POSIX file types (C<EIO_DT_REG>, C<EIO_DT_DIR>, C<EIO_DT_LNK>,
		460	C<EIO_DT_FIFO>, C<EIO_DT_SOCK>, C<EIO_DT_CHR>, C<EIO_DT_BLK>)
		461	or some OS-specific type (currently
		462	C<EIO_DT_MPC> - multiplexed char device (v7+coherent),
		463	C<EIO_DT_NAM> - xenix special named file,
		464	C<EIO_DT_MPB> - multiplexed block device (v7+coherent),
		465	C<EIO_DT_NWK> - HP-UX network special,
		466	C<EIO_DT_CMP> - VxFS compressed,
		467	C<EIO_DT_DOOR> - solaris door, or
		468	C<EIO_DT_WHT>).
		469
		470	This example prints all names and their type:
		471
		472	int i;
		473	struct eio_dirent ents = (struct eio_dirent )req->ptr1;
		474	char names = (char )req->ptr2;
		475
		476	for (i = 0; i < req->result; ++i)
		477	{
		478	struct eio_dirent *ent = ents + i;
		479	char *name = names + ent->nameofs;
		480
		481	printf ("name #%d: %s (type %d)\n", i, name, ent->type);
		482	}
		483
		484	=item EIO_READDIR_DIRS_FIRST
		485
		486	When this flag is specified, then the names will be returned in an order
		487	where likely directories come first, in optimal C<stat> order. This is
		488	useful when you need to quickly find directories, or you want to find all
		489	directories while avoiding to stat() each entry.
		490
		491	If the system returns type information in readdir, then this is used
		492	to find directories directly. Otherwise, likely directories are names
		493	beginning with ".", or otherwise names with no dots, of which names with
		494	short names are tried first.
		495
		496	=item EIO_READDIR_STAT_ORDER
		497
		498	When this flag is specified, then the names will be returned in an order
		499	suitable for stat()'ing each one. That is, when you plan to stat()
		500	all files in the given directory, then the returned order will likely
		501	be fastest.
		502
		503	If both this flag and C<EIO_READDIR_DIRS_FIRST> are specified, then
		504	the likely dirs come first, resulting in a less optimal stat order.
		505
		506	=item EIO_READDIR_FOUND_UNKNOWN
		507
		508	This flag should not be specified when calling C<eio_readdir>. Instead,
		509	it is being set by C<eio_readdir> (you can access the C<flags> via C<<
		510	req->int1 >>, when any of the C<type>'s found were C<EIO_DT_UNKNOWN>. The
		511	absense of this flag therefore indicates that all C<type>'s are known,
		512	which can be used to speed up some algorithms.
		513
		514	A typical use case would be to identify all subdirectories within a
		515	directory - you would ask C<eio_readdir> for C<EIO_READDIR_DIRS_FIRST>. If
		516	then this flag is I<NOT> set, then all the entries at the beginning of the
		517	returned array of type C<EIO_DT_DIR> are the directories. Otherwise, you
		518	should start C<stat()>'ing the entries starting at the beginning of the
		519	array, stopping as soon as you found all directories (the count can be
		520	deduced by the link count of the directory).
		521
		522	=back
		523
		524	=back
		525
		526	=head3 OS-SPECIFIC CALL WRAPPERS
		527
		528	These wrap OS-specific calls (usually Linux ones), and might or might not
		529	be emulated on other operating systems. Calls that are not emulated will
		530	return C<-1> and set C<errno> to C<ENOSYS>.
		531
		532	=over 4
		533
		534	=item eio_sendfile (int out_fd, int in_fd, off_t in_offset, size_t length, int pri, eio_cb cb, void *data)
		535
		536	Wraps the C<sendfile> syscall. The arguments follow the Linux version, but
		537	libeio supports and will use similar calls on FreeBSD, HP/UX, Solaris and
		538	Darwin.
		539
		540	If the OS doesn't support some sendfile-like call, or the call fails,
		541	indicating support for the given file descriptor type (for example,
		542	Linux's sendfile might not support file to file copies), then libeio will
		543	emulate the call in userspace, so there are almost no limitations on its
		544	use.
		545
		546	=item eio_readahead (int fd, off_t offset, size_t length, int pri, eio_cb cb, void *data)
		547
		548	Calls C<readahead(2)>. If the syscall is missing, then the call is
		549	emulated by simply reading the data (currently in 64kiB chunks).
		550
		551	=item eio_sync_file_range (int fd, off_t offset, size_t nbytes, unsigned int flags, int pri, eio_cb cb, void *data)
		552
		553	Calls C<sync_file_range>. If the syscall is missing, then this is the same
		554	as calling C<fdatasync>.
		555
		556	Flags can be any combination of C<EIO_SYNC_FILE_RANGE_WAIT_BEFORE>,
		557	C<EIO_SYNC_FILE_RANGE_WRITE> and C<EIO_SYNC_FILE_RANGE_WAIT_AFTER>.
		558
		559	=back
		560
		561	=head3 LIBEIO-SPECIFIC REQUESTS
		562
		563	These requests are specific to libeio and do not correspond to any OS call.
		564
		565	=over 4
		566
		567	=item eio_mtouch (void addr, size_t length, int flags, int pri, eio_cb cb, void data)
		568
		569	Reads (C<flags == 0>) or modifies (C<flags == EIO_MT_MODIFY) the given
		570	memory area, page-wise, that is, it reads (or reads and writes back) the
		571	first octet of every page that spans the memory area.
		572
		573	This can be used to page in some mmapped file, or dirty some pages. Note
		574	that dirtying is an unlocked read-write access, so races can ensue when
		575	the some other thread modifies the data stored in that memory area.
		576
		577	=item eio_custom (void ()(eio_req ) execute, int pri, eio_cb cb, void *data)
		578
		579	Executes a custom request, i.e., a user-specified callback.
		580
		581	The callback gets the C<eio_req *> as parameter and is expected to read
		582	and modify any request-specific members. Specifically, it should set C<<
		583	req->result >> to the result value, just like other requests.
		584
		585	Here is an example that simply calls C<open>, like C<eio_open>, but it
		586	uses the C<data> member as filename and uses a hardcoded C<O_RDONLY>. If
		587	you want to pass more/other parameters, you either need to pass some
		588	struct or so via C<data> or provide your own wrapper using the low-level
		589	API.
		590
		591	static int
		592	my_open_done (eio_req *req)
		593	{
		594	int fd = req->result;
		595
		596	return 0;
		597	}
		598
		599	static void
		600	my_open (eio_req *req)
		601	{
		602	req->result = open (req->data, O_RDONLY);
		603	}
		604
		605	eio_custom (my_open, 0, my_open_done, "/etc/passwd");
		606
		607	=item eio_busy (eio_tstamp delay, int pri, eio_cb cb, void *data)
		608
		609	This is a a request that takes C<delay> seconds to execute, but otherwise
		610	does nothing - it simply puts one of the worker threads to sleep for this
		611	long.
		612
		613	This request can be used to artificially increase load, e.g. for debugging
		614	or benchmarking reasons.
		615
		616	=item eio_nop (int pri, eio_cb cb, void *data)
		617
		618	This request does nothing, except go through the whole request cycle. This
		619	can be used to measure latency or in some cases to simplify code, but is
		620	not really of much use.
		621
		622	=back
		623
		624	=head3 GROUPING AND LIMITING REQUESTS
		625
		626	There is one more rather special request, C<eio_grp>. It is a very special
		627	aio request: Instead of doing something, it is a container for other eio
		628	requests.
		629
		630	There are two primary use cases for this: a) bundle many requests into a
		631	single, composite, request with a definite callback and the ability to
		632	cancel the whole request with its subrequests and b) limiting the number
		633	of "active" requests.
		634
		635	Further below you will find more dicussion of these topics - first follows
		636	the reference section detailing the request generator and other methods.
		637
		638	=over 4
		639
		640	=item eio_grp (eio_cb cb, void *data)
		641
		642	Creates and submits a group request.
		643
		644	=back
		645
		646
		647
		648	#TODO
		649
		650	/*****************************************************************************/
		651	/* groups */
		652
		653	eio_req eio_grp (eio_cb cb, void data);
		654	void eio_grp_feed (eio_req grp, void (feed)(eio_req *req), int limit);
		655	void eio_grp_limit (eio_req *grp, int limit);
		656	void eio_grp_add (eio_req grp, eio_req req);
		657	void eio_grp_cancel (eio_req grp); / cancels all sub requests but not the group */
		658
		659
		660	=back
		661
		662
		663	=head1 LOW LEVEL REQUEST API
		664
		665	#TODO
		666
		667
		668	=head1 ANATOMY AND LIFETIME OF AN EIO REQUEST
		669
		670	A request is represented by a structure of type C<eio_req>. To initialise
		671	it, clear it to all zero bytes:
		672
		673	eio_req req;
		674
		675	memset (&req, 0, sizeof (req));
		676
		677	A more common way to initialise a new C<eio_req> is to use C<calloc>:
		678
		679	eio_req req = calloc (1, sizeof (req));
		680
		681	In either case, libeio neither allocates, initialises or frees the
		682	C<eio_req> structure for you - it merely uses it.
		683
		684	zero
		685
		686	#TODO
		687
138	=head2 CONFIGURATION	688	=head2 CONFIGURATION
139		689
140	The functions in this section can sometimes be useful, but the default	690	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	691	configuration will do in most case, so you should skip this section on
142	first reading.	692	first reading.
…		…
185	=item eio_set_max_idle (unsigned int nthreads)	735	=item eio_set_max_idle (unsigned int nthreads)
186		736
187	Libeio uses threads internally to handle most requests, and will start and stop threads on demand.	737	Libeio uses threads internally to handle most requests, and will start and stop threads on demand.
188		738
189	This call can be used to limit the number of idle threads (threads without	739	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	740	work to do): libeio will keep some threads idle in preparation for more
191	requests, but never longer than C<nthreads> threads.	741	requests, but never longer than C<nthreads> threads.
192		742
193	In addition to this, libeio will also stop threads when they are idle for	743	In addition to this, libeio will also stop threads when they are idle for
194	a few seconds, regardless of this setting.	744	a few seconds, regardless of this setting.
195		745
…		…
214	executed and have results, but have not been finished yet by a call to	764	executed and have results, but have not been finished yet by a call to
215	C<eio_poll>).	765	C<eio_poll>).
216		766
217	=back	767	=back
218		768
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	769	=head1 EMBEDDING
237		770
238	Libeio can be embedded directly into programs. This functionality is not	771	Libeio can be embedded directly into programs. This functionality is not
239	documented and not (yet) officially supported.	772	documented and not (yet) officially supported.
240		773
241	Note that, when including C<libeio.m4>, you are responsible for defining	774	Note that, when including C<libeio.m4>, you are responsible for defining
242	the compilation environment (C<_LARGEFILE_SOURCE>, C<_GNU_SOURCE> etc.).	775	the compilation environment (C<_LARGEFILE_SOURCE>, C<_GNU_SOURCE> etc.).
243		776
244	If you need to know how, check the C<IO::AIO> perl module, which does	777	If you need to know how, check the C<IO::AIO> perl module, which does
245	exactly that.	778	exactly that.
		779
		780
		781	=head1 COMPILETIME CONFIGURATION
		782
		783	These symbols, if used, must be defined when compiling F<eio.c>.
		784
		785	=over 4
		786
		787	=item EIO_STACKSIZE
		788
		789	This symbol governs the stack size for each eio thread. Libeio itself
		790	was written to use very little stackspace, but when using C<EIO_CUSTOM>
		791	requests, you might want to increase this.
		792
		793	If this symbol is undefined (the default) then libeio will use its default
		794	stack size (C<sizeof (long) * 4096> currently). If it is defined, but
		795	C<0>, then the default operating system stack size will be used. In all
		796	other cases, the value must be an expression that evaluates to the desired
		797	stack size.
		798
		799	=back
246		800
247		801
248	=head1 PORTABILITY REQUIREMENTS	802	=head1 PORTABILITY REQUIREMENTS
249		803
250	In addition to a working ISO-C implementation, libeio relies on a few	804	In addition to a working ISO-C implementation, libeio relies on a few

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing libeio/eio.pod (file contents): Revision 1.3 by root, Wed Oct 22 18:15:36 2008 UTC vs. Revision 1.15 by root, Tue Jul 5 16:57:41 2011 UTC

Diff Legend

Comparing libeio/eio.pod (file contents):
Revision 1.3 by root, Wed Oct 22 18:15:36 2008 UTC vs.
Revision 1.15 by root, Tue Jul 5 16:57:41 2011 UTC