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

Comparing libeio/eio.pod (file contents):
Revision 1.1 by root, Sun May 11 13:05:10 2008 UTC vs.
Revision 1.12 by root, Wed Jun 29 10:32:55 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
…		…
126	libev resets/rearms the async watcher before calling your callback,	131	libev resets/rearms the async watcher before calling your callback,
127	and therefore, before calling C<eio_poll>. This might result in (some)	132	and therefore, before calling C<eio_poll>. This might result in (some)
128	spurious wake-ups, but is generally harmless.	133	spurious wake-ups, but is generally harmless.
129		134
130	For most other event loops, you would typically use a pipe - the event	135	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	136	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	137	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	138	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	139	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	140	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>).	141	read callback does not read it, only C<done_poll>).
137		142
		143
		144	=head1 HIGH LEVEL REQUEST API
		145
		146	Libeio has both a high-level API, which consists of calling a request
		147	function with a callback to be called on completion, and a low-level API
		148	where you fill out request structures and submit them.
		149
		150	This section describes the high-level API.
		151
		152	=head2 REQUEST SUBMISSION AND RESULT PROCESSING
		153
		154	You submit a request by calling the relevant C<eio_TYPE> function with the
		155	required parameters, a callback of type C<int (eio_cb)(eio_req req)>
		156	(called C<eio_cb> below) and a freely usable C<void *data> argument.
		157
		158	The return value will either be 0, in case something went really wrong
		159	(which can basically only happen on very fatal errors, such as C<malloc>
		160	returning 0, which is rather unlikely), or a pointer to the newly-created
		161	and submitted C<eio_req *>.
		162
		163	The callback will be called with an C<eio_req *> which contains the
		164	results of the request. The members you can access inside that structure
		165	vary from request to request, except for:
		166
		167	=over 4
		168
		169	=item C<ssize_t result>
		170
		171	This contains the result value from the call (usually the same as the
		172	syscall of the same name).
		173
		174	=item C<int errorno>
		175
		176	This contains the value of C<errno> after the call.
		177
		178	=item C<void *data>
		179
		180	The C<void *data> member simply stores the value of the C<data> argument.
		181
		182	=back
		183
		184	The return value of the callback is normally C<0>, which tells libeio to
		185	continue normally. If a callback returns a nonzero value, libeio will
		186	stop processing results (in C<eio_poll>) and will return the value to its
		187	caller.
		188
		189	Memory areas passed to libeio must stay valid as long as a request
		190	executes, with the exception of paths, which are being copied
		191	internally. Any memory libeio itself allocates will be freed after the
		192	finish callback has been called. If you want to manage all memory passed
		193	to libeio yourself you can use the low-level API.
		194
		195	For example, to open a file, you could do this:
		196
		197	static int
		198	file_open_done (eio_req *req)
		199	{
		200	if (req->result < 0)
		201	{
		202	/* open() returned -1 */
		203	errno = req->errorno;
		204	perror ("open");
		205	}
		206	else
		207	{
		208	int fd = req->result;
		209	/* now we have the new fd in fd */
		210	}
		211
		212	return 0;
		213	}
		214
		215	/* the first three arguments are passed to open(2) */
		216	/* the remaining are priority, callback and data */
		217	if (!eio_open ("/etc/passwd", O_RDONLY, 0, 0, file_open_done, 0))
		218	abort (); /* something ent wrong, we will all die!!! */
		219
		220	Note that you additionally need to call C<eio_poll> when the C<want_cb>
		221	indicates that requests are ready to be processed.
		222
		223	=head2 AVAILABLE REQUESTS
		224
		225	The following request functions are available. I<All> of them return the
		226	C<eio_req *> on success and C<0> on failure, and I<all> of them have the
		227	same three trailing arguments: C<pri>, C<cb> and C<data>. The C<cb> is
		228	mandatory, but in most cases, you pass in C<0> as C<pri> and C<0> or some
		229	custom data value as C<data>.
		230
		231	=head3 POSIX API WRAPPERS
		232
		233	These requests simply wrap the POSIX call of the same name, with the same
		234	arguments. If a function is not implemented by the OS and cannot be emulated
		235	in some way, then all of these return C<-1> and set C<errorno> to C<ENOSYS>.
		236
		237	=over 4
		238
		239	=item eio_open (const char path, int flags, mode_t mode, int pri, eio_cb cb, void data)
		240
		241	=item eio_truncate (const char path, off_t offset, int pri, eio_cb cb, void data)
		242
		243	=item eio_chown (const char path, uid_t uid, gid_t gid, int pri, eio_cb cb, void data)
		244
		245	=item eio_chmod (const char path, mode_t mode, int pri, eio_cb cb, void data)
		246
		247	=item eio_mkdir (const char path, mode_t mode, int pri, eio_cb cb, void data)
		248
		249	=item eio_rmdir (const char path, int pri, eio_cb cb, void data)
		250
		251	=item eio_unlink (const char path, int pri, eio_cb cb, void data)
		252
		253	=item eio_utime (const char path, eio_tstamp atime, eio_tstamp mtime, int pri, eio_cb cb, void data)
		254
		255	=item eio_mknod (const char path, mode_t mode, dev_t dev, int pri, eio_cb cb, void data)
		256
		257	=item eio_link (const char path, const char new_path, int pri, eio_cb cb, void *data)
		258
		259	=item eio_symlink (const char path, const char new_path, int pri, eio_cb cb, void *data)
		260
		261	=item eio_rename (const char path, const char new_path, int pri, eio_cb cb, void *data)
		262
		263	=item eio_mlock (void addr, size_t length, int pri, eio_cb cb, void data)
		264
		265	=item eio_close (int fd, int pri, eio_cb cb, void *data)
		266
		267	=item eio_sync (int pri, eio_cb cb, void *data)
		268
		269	=item eio_fsync (int fd, int pri, eio_cb cb, void *data)
		270
		271	=item eio_fdatasync (int fd, int pri, eio_cb cb, void *data)
		272
		273	=item eio_futime (int fd, eio_tstamp atime, eio_tstamp mtime, int pri, eio_cb cb, void *data)
		274
		275	=item eio_ftruncate (int fd, off_t offset, int pri, eio_cb cb, void *data)
		276
		277	=item eio_fchmod (int fd, mode_t mode, int pri, eio_cb cb, void *data)
		278
		279	=item eio_fchown (int fd, uid_t uid, gid_t gid, int pri, eio_cb cb, void *data)
		280
		281	=item eio_dup2 (int fd, int fd2, int pri, eio_cb cb, void *data)
		282
		283	These have the same semantics as the syscall of the same name, their
		284	return value is available as C<< req->result >> later.
		285
		286	=item eio_read (int fd, void buf, size_t length, off_t offset, int pri, eio_cb cb, void data)
		287
		288	=item eio_write (int fd, void buf, size_t length, off_t offset, int pri, eio_cb cb, void data)
		289
		290	These two requests are called C<read> and C<write>, but actually wrap
		291	C<pread> and C<pwrite>. On systems that lack these calls (such as cygwin),
		292	libeio uses lseek/read_or_write/lseek and a mutex to serialise the
		293	requests, so all these requests run serially and do not disturb each
		294	other. However, they still disturb the file offset while they run, so it's
		295	not safe to call these functions concurrently with non-libeio functions on
		296	the same fd on these systems.
		297
		298	Not surprisingly, pread and pwrite are not thread-safe on Darwin (OS/X),
		299	so it is advised not to submit multiple requests on the same fd on this
		300	horrible pile of garbage.
		301
		302	=item eio_mlockall (int flags, int pri, eio_cb cb, void *data)
		303
		304	Like C<mlockall>, but the flag value constants are called
		305	C<EIO_MCL_CURRENT> and C<EIO_MCL_FUTURE>.
		306
		307	=item eio_msync (void addr, size_t length, int flags, int pri, eio_cb cb, void data)
		308
		309	Just like msync, except that the flag values are called C<EIO_MS_ASYNC>,
		310	C<EIO_MS_INVALIDATE> and C<EIO_MS_SYNC>.
		311
		312	=item eio_readlink (const char path, int pri, eio_cb cb, void data)
		313
		314	If successful, the path read by C<readlink(2)> can be accessed via C<<
		315	req->ptr2 >> and is I<NOT> null-terminated, with the length specified as
		316	C<< req->result >>.
		317
		318	if (req->result >= 0)
		319	{
		320	char target = strndup ((char )req->ptr2, req->result);
		321
		322	free (target);
		323	}
		324
		325	=item eio_stat (const char path, int pri, eio_cb cb, void data)
		326
		327	=item eio_lstat (const char path, int pri, eio_cb cb, void data)
		328
		329	=item eio_fstat (int fd, int pri, eio_cb cb, void *data)
		330
		331	Stats a file - if C<< req->result >> indicates success, then you can
		332	access the C<struct stat>-like structure via C<< req->ptr2 >>:
		333
		334	EIO_STRUCT_STAT statdata = (EIO_STRUCT_STAT )req->ptr2;
		335
		336	=item eio_statvfs (const char path, int pri, eio_cb cb, void data)
		337
		338	=item eio_fstatvfs (int fd, int pri, eio_cb cb, void *data)
		339
		340	Stats a filesystem - if C<< req->result >> indicates success, then you can
		341	access the C<struct statvfs>-like structure via C<< req->ptr2 >>:
		342
		343	EIO_STRUCT_STATVFS statdata = (EIO_STRUCT_STATVFS )req->ptr2;
		344
		345	=back
		346
		347	=head3 READING DIRECTORIES
		348
		349	Reading directories sounds simple, but can be rather demanding, especially
		350	if you want to do stuff such as traversing a diretcory hierarchy or
		351	processing all files in a directory. Libeio can assist thess complex tasks
		352	with it's C<eio_readdir> call.
		353
		354	=over 4
		355
		356	=item eio_readdir (const char path, int flags, int pri, eio_cb cb, void data)
		357
		358	This is a very complex call. It basically reads through a whole directory
		359	(via the C<opendir>, C<readdir> and C<closedir> calls) and returns either
		360	the names or an array of C<struct eio_dirent>, depending on the C<flags>
		361	argument.
		362
		363	The C<< req->result >> indicates either the number of files found, or
		364	C<-1> on error. On success, null-terminated names can be found as C<< req->ptr2 >>,
		365	and C<struct eio_dirents>, if requested by C<flags>, can be found via C<<
		366	req->ptr1 >>.
		367
		368	Here is an example that prints all the names:
		369
		370	int i;
		371	char names = (char )req->ptr2;
		372
		373	for (i = 0; i < req->result; ++i)
		374	{
		375	printf ("name #%d: %s\n", i, names);
		376
		377	/* move to next name */
		378	names += strlen (names) + 1;
		379	}
		380
		381	Pseudo-entries such as F<.> and F<..> are never returned by C<eio_readdir>.
		382
		383	C<flags> can be any combination of:
		384
		385	=over 4
		386
		387	=item EIO_READDIR_DENTS
		388
		389	If this flag is specified, then, in addition to the names in C<ptr2>,
		390	also an array of C<struct eio_dirent> is returned, in C<ptr1>. A C<struct
		391	eio_dirent> looks like this:
		392
		393	struct eio_dirent
		394	{
		395	int nameofs; /* offset of null-terminated name string in (char )req->ptr2 /
		396	unsigned short namelen; /* size of filename without trailing 0 */
		397	unsigned char type; /* one of EIO_DT_* */
		398	signed char score; /* internal use */
		399	ino_t inode; /* the inode number, if available, otherwise unspecified */
		400	};
		401
		402	The only members you normally would access are C<nameofs>, which is the
		403	byte-offset from C<ptr2> to the start of the name, C<namelen> and C<type>.
		404
		405	C<type> can be one of:
		406
		407	C<EIO_DT_UNKNOWN> - if the type is not known (very common) and you have to C<stat>
		408	the name yourself if you need to know,
		409	one of the "standard" POSIX file types (C<EIO_DT_REG>, C<EIO_DT_DIR>, C<EIO_DT_LNK>,
		410	C<EIO_DT_FIFO>, C<EIO_DT_SOCK>, C<EIO_DT_CHR>, C<EIO_DT_BLK>)
		411	or some OS-specific type (currently
		412	C<EIO_DT_MPC> - multiplexed char device (v7+coherent),
		413	C<EIO_DT_NAM> - xenix special named file,
		414	C<EIO_DT_MPB> - multiplexed block device (v7+coherent),
		415	C<EIO_DT_NWK> - HP-UX network special,
		416	C<EIO_DT_CMP> - VxFS compressed,
		417	C<EIO_DT_DOOR> - solaris door, or
		418	C<EIO_DT_WHT>).
		419
		420	This example prints all names and their type:
		421
		422	int i;
		423	struct eio_dirent ents = (struct eio_dirent )req->ptr1;
		424	char names = (char )req->ptr2;
		425
		426	for (i = 0; i < req->result; ++i)
		427	{
		428	struct eio_dirent *ent = ents + i;
		429	char *name = names + ent->nameofs;
		430
		431	printf ("name #%d: %s (type %d)\n", i, name, ent->type);
		432	}
		433
		434	=item EIO_READDIR_DIRS_FIRST
		435
		436	When this flag is specified, then the names will be returned in an order
		437	where likely directories come first, in optimal C<stat> order. This is
		438	useful when you need to quickly find directories, or you want to find all
		439	directories while avoiding to stat() each entry.
		440
		441	If the system returns type information in readdir, then this is used
		442	to find directories directly. Otherwise, likely directories are names
		443	beginning with ".", or otherwise names with no dots, of which names with
		444	short names are tried first.
		445
		446	=item EIO_READDIR_STAT_ORDER
		447
		448	When this flag is specified, then the names will be returned in an order
		449	suitable for stat()'ing each one. That is, when you plan to stat()
		450	all files in the given directory, then the returned order will likely
		451	be fastest.
		452
		453	If both this flag and C<EIO_READDIR_DIRS_FIRST> are specified, then
		454	the likely dirs come first, resulting in a less optimal stat order.
		455
		456	=item EIO_READDIR_FOUND_UNKNOWN
		457
		458	This flag should not be specified when calling C<eio_readdir>. Instead,
		459	it is being set by C<eio_readdir> (you can access the C<flags> via C<<
		460	req->int1 >>, when any of the C<type>'s found were C<EIO_DT_UNKNOWN>. The
		461	absense of this flag therefore indicates that all C<type>'s are known,
		462	which can be used to speed up some algorithms.
		463
		464	A typical use case would be to identify all subdirectories within a
		465	directory - you would ask C<eio_readdir> for C<EIO_READDIR_DIRS_FIRST>. If
		466	then this flag is I<NOT> set, then all the entries at the beginning of the
		467	returned array of type C<EIO_DT_DIR> are the directories. Otherwise, you
		468	should start C<stat()>'ing the entries starting at the beginning of the
		469	array, stopping as soon as you found all directories (the count can be
		470	deduced by the link count of the directory).
		471
		472	=back
		473
		474	=back
		475
		476	=head3 OS-SPECIFIC CALL WRAPPERS
		477
		478	These wrap OS-specific calls (usually Linux ones), and might or might not
		479	be emulated on other operating systems. Calls that are not emulated will
		480	return C<-1> and set C<errno> to C<ENOSYS>.
		481
		482	=over 4
		483
		484	=item eio_sendfile (int out_fd, int in_fd, off_t in_offset, size_t length, int pri, eio_cb cb, void *data)
		485
		486	Wraps the C<sendfile> syscall. The arguments follow the Linux version, but
		487	libeio supports and will use similar calls on FreeBSD, HP/UX, Solaris and
		488	Darwin.
		489
		490	If the OS doesn't support some sendfile-like call, or the call fails,
		491	indicating support for the given file descriptor type (for example,
		492	Linux's sendfile might not support file to file copies), then libeio will
		493	emulate the call in userspace, so there are almost no limitations on its
		494	use.
		495
		496	=item eio_readahead (int fd, off_t offset, size_t length, int pri, eio_cb cb, void *data)
		497
		498	Calls C<readahead(2)>. If the syscall is missing, then the call is
		499	emulated by simply reading the data (currently in 64kiB chunks).
		500
		501	=item eio_sync_file_range (int fd, off_t offset, size_t nbytes, unsigned int flags, int pri, eio_cb cb, void *data)
		502
		503	Calls C<sync_file_range>. If the syscall is missing, then this is the same
		504	as calling C<fdatasync>.
		505
		506	Flags can be any combination of C<EIO_SYNC_FILE_RANGE_WAIT_BEFORE>,
		507	C<EIO_SYNC_FILE_RANGE_WRITE> and C<EIO_SYNC_FILE_RANGE_WAIT_AFTER>.
		508
		509	=back
		510
		511	=head3 LIBEIO-SPECIFIC REQUESTS
		512
		513	These requests are specific to libeio and do not correspond to any OS call.
		514
		515	=over 4
		516
		517	=item eio_mtouch (void addr, size_t length, int flags, int pri, eio_cb cb, void data)
		518
		519	Reads (C<flags == 0>) or modifies (C<flags == EIO_MT_MODIFY) the given
		520	memory area, page-wise, that is, it reads (or reads and writes back) the
		521	first octet of every page that spans the memory area.
		522
		523	This can be used to page in some mmapped file, or dirty some pages. Note
		524	that dirtying is an unlocked read-write access, so races can ensue when
		525	the some other thread modifies the data stored in that memory area.
		526
		527	=item eio_custom (void ()(eio_req ) execute, int pri, eio_cb cb, void *data)
		528
		529	Executes a custom request, i.e., a user-specified callback.
		530
		531	The callback gets the C<eio_req *> as parameter and is expected to read
		532	and modify any request-specific members. Specifically, it should set C<<
		533	req->result >> to the result value, just like other requests.
		534
		535	Here is an example that simply calls C<open>, like C<eio_open>, but it
		536	uses the C<data> member as filename and uses a hardcoded C<O_RDONLY>. If
		537	you want to pass more/other parameters, you either need to pass some
		538	struct or so via C<data> or provide your own wrapper using the low-level
		539	API.
		540
		541	static int
		542	my_open_done (eio_req *req)
		543	{
		544	int fd = req->result;
		545
		546	return 0;
		547	}
		548
		549	static void
		550	my_open (eio_req *req)
		551	{
		552	req->result = open (req->data, O_RDONLY);
		553	}
		554
		555	eio_custom (my_open, 0, my_open_done, "/etc/passwd");
		556
		557	=item eio_busy (eio_tstamp delay, int pri, eio_cb cb, void *data)
		558
		559	This is a a request that takes C<delay> seconds to execute, but otherwise
		560	does nothing - it simply puts one of the worker threads to sleep for this
		561	long.
		562
		563	This request can be used to artificially increase load, e.g. for debugging
		564	or benchmarking reasons.
		565
		566	=item eio_nop (int pri, eio_cb cb, void *data)
		567
		568	This request does nothing, except go through the whole request cycle. This
		569	can be used to measure latency or in some cases to simplify code, but is
		570	not really of much use.
		571
		572	=back
		573
		574	=head3 GROUPING AND LIMITING REQUESTS
		575
		576	There is one more rather special request, C<eio_grp>. It is a very special
		577	aio request: Instead of doing something, it is a container for other eio
		578	requests.
		579
		580	There are two primary use cases for this: a) bundle many requests into a
		581	single, composite, request with a definite callback and the ability to
		582	cancel the whole request with its subrequests and b) limiting the number
		583	of "active" requests.
		584
		585	Further below you will find more dicussion of these topics - first follows
		586	the reference section detailing the request generator and other methods.
		587
		588	=over 4
		589
		590	=item eio_grp (eio_cb cb, void *data)
		591
		592	Creates and submits a group request.
		593
		594	=back
		595
		596
		597
		598	#TODO
		599
		600	/*****************************************************************************/
		601	/* groups */
		602
		603	eio_req eio_grp (eio_cb cb, void data);
		604	void eio_grp_feed (eio_req grp, void (feed)(eio_req *req), int limit);
		605	void eio_grp_limit (eio_req *grp, int limit);
		606	void eio_grp_add (eio_req grp, eio_req req);
		607	void eio_grp_cancel (eio_req grp); / cancels all sub requests but not the group */
		608
		609
		610	=back
		611
		612
		613	=head1 LOW LEVEL REQUEST API
		614
		615	#TODO
		616
		617
		618	=head1 ANATOMY AND LIFETIME OF AN EIO REQUEST
		619
		620	A request is represented by a structure of type C<eio_req>. To initialise
		621	it, clear it to all zero bytes:
		622
		623	eio_req req;
		624
		625	memset (&req, 0, sizeof (req));
		626
		627	A more common way to initialise a new C<eio_req> is to use C<calloc>:
		628
		629	eio_req req = calloc (1, sizeof (req));
		630
		631	In either case, libeio neither allocates, initialises or frees the
		632	C<eio_req> structure for you - it merely uses it.
		633
		634	zero
		635
		636	#TODO
		637
138	=head2 CONFIGURATION	638	=head2 CONFIGURATION
139		639
140	The functions in this section can sometimes be useful, but the default	640	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	641	configuration will do in most case, so you should skip this section on
142	first reading.	642	first reading.
…		…
185	=item eio_set_max_idle (unsigned int nthreads)	685	=item eio_set_max_idle (unsigned int nthreads)
186		686
187	Libeio uses threads internally to handle most requests, and will start and stop threads on demand.	687	Libeio uses threads internally to handle most requests, and will start and stop threads on demand.
188		688
189	This call can be used to limit the number of idle threads (threads without	689	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	690	work to do): libeio will keep some threads idle in preparation for more
191	requests, but never longer than C<nthreads> threads.	691	requests, but never longer than C<nthreads> threads.
192		692
193	In addition to this, libeio will also stop threads when they are idle for	693	In addition to this, libeio will also stop threads when they are idle for
194	a few seconds, regardless of this setting.	694	a few seconds, regardless of this setting.
195		695
…		…
214	executed and have results, but have not been finished yet by a call to	714	executed and have results, but have not been finished yet by a call to
215	C<eio_poll>).	715	C<eio_poll>).
216		716
217	=back	717	=back
218		718
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	719	=head1 EMBEDDING
237		720
238	Libeio can be embedded directly into programs. This functionality is not	721	Libeio can be embedded directly into programs. This functionality is not
239	documented and not (yet) officially supported.	722	documented and not (yet) officially supported.
240		723
		724	Note that, when including C<libeio.m4>, you are responsible for defining
		725	the compilation environment (C<_LARGEFILE_SOURCE>, C<_GNU_SOURCE> etc.).
		726
241	If you ened to know how, cehck the C<IO::AIO> perl module, which does	727	If you need to know how, check the C<IO::AIO> perl module, which does
242	exactly that.	728	exactly that.
		729
		730
		731	=head1 COMPILETIME CONFIGURATION
		732
		733	These symbols, if used, must be defined when compiling F<eio.c>.
		734
		735	=over 4
		736
		737	=item EIO_STACKSIZE
		738
		739	This symbol governs the stack size for each eio thread. Libeio itself
		740	was written to use very little stackspace, but when using C<EIO_CUSTOM>
		741	requests, you might want to increase this.
		742
		743	If this symbol is undefined (the default) then libeio will use its default
		744	stack size (C<sizeof (long) * 4096> currently). If it is defined, but
		745	C<0>, then the default operating system stack size will be used. In all
		746	other cases, the value must be an expression that evaluates to the desired
		747	stack size.
		748
		749	=back
243		750
244		751
245	=head1 PORTABILITY REQUIREMENTS	752	=head1 PORTABILITY REQUIREMENTS
246		753
247	In addition to a working ISO-C implementation, libeio relies on a few	754	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.1 by root, Sun May 11 13:05:10 2008 UTC vs. Revision 1.12 by root, Wed Jun 29 10:32:55 2011 UTC

Diff Legend

Comparing libeio/eio.pod (file contents):
Revision 1.1 by root, Sun May 11 13:05:10 2008 UTC vs.
Revision 1.12 by root, Wed Jun 29 10:32:55 2011 UTC