[ViewVC] Diff of: cvs/libev/ev.pod

Comparing libev/ev.pod (file contents):
Revision 1.231 by root, Wed Apr 15 19:35:53 2009 UTC vs.
Revision 1.238 by root, Sat Apr 18 12:10:41 2009 UTC

…		…
62		62
63	// unloop was called, so exit	63	// unloop was called, so exit
64	return 0;	64	return 0;
65	}	65	}
66		66
67	=head1 DESCRIPTION	67	=head1 ABOUT THIS DOCUMENT
		68
		69	This document documents the libev software package.
68		70
69	The newest version of this document is also available as an html-formatted	71	The newest version of this document is also available as an html-formatted
70	web page you might find easier to navigate when reading it for the first	72	web page you might find easier to navigate when reading it for the first
71	time: L<http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod>.	73	time: L<http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod>.
		74
		75	While this document tries to be as complete as possible in documenting
		76	libev, its usage and the rationale behind its design, it is not a tutorial
		77	on event-based programming, nor will it introduce event-based programming
		78	with libev.
		79
		80	Familarity with event based programming techniques in general is assumed
		81	throughout this document.
		82
		83	=head1 ABOUT LIBEV
72		84
73	Libev is an event loop: you register interest in certain events (such as a	85	Libev is an event loop: you register interest in certain events (such as a
74	file descriptor being readable or a timeout occurring), and it will manage	86	file descriptor being readable or a timeout occurring), and it will manage
75	these event sources and provide your program with events.	87	these event sources and provide your program with events.
76		88
…		…
110	name C<loop> (which is always of type C<ev_loop *>) will not have	122	name C<loop> (which is always of type C<ev_loop *>) will not have
111	this argument.	123	this argument.
112		124
113	=head2 TIME REPRESENTATION	125	=head2 TIME REPRESENTATION
114		126
115	Libev represents time as a single floating point number, representing the	127	Libev represents time as a single floating point number, representing
116	(fractional) number of seconds since the (POSIX) epoch (somewhere near	128	the (fractional) number of seconds since the (POSIX) epoch (somewhere
117	the beginning of 1970, details are complicated, don't ask). This type is	129	near the beginning of 1970, details are complicated, don't ask). This
118	called C<ev_tstamp>, which is what you should use too. It usually aliases	130	type is called C<ev_tstamp>, which is what you should use too. It usually
119	to the C<double> type in C, and when you need to do any calculations on	131	aliases to the C<double> type in C. When you need to do any calculations
120	it, you should treat it as some floating point value. Unlike the name	132	on it, you should treat it as some floating point value. Unlike the name
121	component C<stamp> might indicate, it is also used for time differences	133	component C<stamp> might indicate, it is also used for time differences
122	throughout libev.	134	throughout libev.
123		135
124	=head1 ERROR HANDLING	136	=head1 ERROR HANDLING
125		137
…		…
632		644
633	This function is rarely useful, but when some event callback runs for a	645	This function is rarely useful, but when some event callback runs for a
634	very long time without entering the event loop, updating libev's idea of	646	very long time without entering the event loop, updating libev's idea of
635	the current time is a good idea.	647	the current time is a good idea.
636		648
637	See also "The special problem of time updates" in the C<ev_timer> section.	649	See also L<The special problem of time updates> in the C<ev_timer> section.
638		650
639	=item ev_suspend (loop)	651	=item ev_suspend (loop)
640		652
641	=item ev_resume (loop)	653	=item ev_resume (loop)
642		654
…		…
1083	integer between C<EV_MAXPRI> (default: C<2>) and C<EV_MINPRI>	1095	integer between C<EV_MAXPRI> (default: C<2>) and C<EV_MINPRI>
1084	(default: C<-2>). Pending watchers with higher priority will be invoked	1096	(default: C<-2>). Pending watchers with higher priority will be invoked
1085	before watchers with lower priority, but priority will not keep watchers	1097	before watchers with lower priority, but priority will not keep watchers
1086	from being executed (except for C<ev_idle> watchers).	1098	from being executed (except for C<ev_idle> watchers).
1087		1099
1088	This means that priorities are I<only> used for ordering callback
1089	invocation after new events have been received. This is useful, for
1090	example, to reduce latency after idling, or more often, to bind two
1091	watchers on the same event and make sure one is called first.
1092
1093	If you need to suppress invocation when higher priority events are pending	1100	If you need to suppress invocation when higher priority events are pending
1094	you need to look at C<ev_idle> watchers, which provide this functionality.	1101	you need to look at C<ev_idle> watchers, which provide this functionality.
1095		1102
1096	You I<must not> change the priority of a watcher as long as it is active or	1103	You I<must not> change the priority of a watcher as long as it is active or
1097	pending.	1104	pending.
1098
1099	The default priority used by watchers when no priority has been set is
1100	always C<0>, which is supposed to not be too high and not be too low :).
1101		1105
1102	Setting a priority outside the range of C<EV_MINPRI> to C<EV_MAXPRI> is	1106	Setting a priority outside the range of C<EV_MINPRI> to C<EV_MAXPRI> is
1103	fine, as long as you do not mind that the priority value you query might	1107	fine, as long as you do not mind that the priority value you query might
1104	or might not have been clamped to the valid range.	1108	or might not have been clamped to the valid range.
		1109
		1110	The default priority used by watchers when no priority has been set is
		1111	always C<0>, which is supposed to not be too high and not be too low :).
		1112
		1113	See L<WATCHER PRIORITY MODELS>, below, for a more thorough treatment of
		1114	priorities.
1105		1115
1106	=item ev_invoke (loop, ev_TYPE *watcher, int revents)	1116	=item ev_invoke (loop, ev_TYPE *watcher, int revents)
1107		1117
1108	Invoke the C<watcher> with the given C<loop> and C<revents>. Neither	1118	Invoke the C<watcher> with the given C<loop> and C<revents>. Neither
1109	C<loop> nor C<revents> need to be valid as long as the watcher callback	1119	C<loop> nor C<revents> need to be valid as long as the watcher callback
…		…
1184	t2_cb (EV_P_ ev_timer *w, int revents)	1194	t2_cb (EV_P_ ev_timer *w, int revents)
1185	{	1195	{
1186	struct my_biggy big = (struct my_biggy *	1196	struct my_biggy big = (struct my_biggy *
1187	(((char *)w) - offsetof (struct my_biggy, t2));	1197	(((char *)w) - offsetof (struct my_biggy, t2));
1188	}	1198	}
		1199
		1200	=head2 WATCHER PRIORITY MODELS
		1201
		1202	Many event loops support I<watcher priorities>, which are usually small
		1203	integers that influence the ordering of event callback invocation
		1204	between watchers in some way, all else being equal.
		1205
		1206	In libev, Watcher priorities can be set using C<ev_set_priority>. See its
		1207	description for the more technical details such as the actual priority
		1208	range.
		1209
		1210	There are two common ways how these these priorities are being interpreted
		1211	by event loops:
		1212
		1213	In the more common lock-out model, higher priorities "lock out" invocation
		1214	of lower priority watchers, which means as long as higher priority
		1215	watchers receive events, lower priority watchers are not being invoked.
		1216
		1217	The less common only-for-ordering model uses priorities solely to order
		1218	callback invocation within a single event loop iteration: Higher priority
		1219	watchers are invoked before lower priority ones, but they all get invoked
		1220	before polling for new events.
		1221
		1222	Libev uses the second (only-for-ordering) model for all its watchers
		1223	except for idle watchers (which use the lock-out model).
		1224
		1225	The rationale behind this is that implementing the lock-out model for
		1226	watchers is not well supported by most kernel interfaces, and most event
		1227	libraries will just poll for the same events again and again as long as
		1228	their callbacks have not been executed, which is very inefficient in the
		1229	common case of one high-priority watcher locking out a mass of lower
		1230	priority ones.
		1231
		1232	Static (ordering) priorities are most useful when you have two or more
		1233	watchers handling the same resource: a typical usage example is having an
		1234	C<ev_io> watcher to receive data, and an associated C<ev_timer> to handle
		1235	timeouts. Under load, data might be received while the program handles
		1236	other jobs, but since timers normally get invoked first, the timeout
		1237	handler will be executed before checking for data. In that case, giving
		1238	the timer a lower priority than the I/O watcher ensures that I/O will be
		1239	handled first even under adverse conditions (which is usually, but not
		1240	always, what you want).
		1241
		1242	Since idle watchers use the "lock-out" model, meaning that idle watchers
		1243	will only be executed when no same or higher priority watchers have
		1244	received events, they can be used to implement the "lock-out" model when
		1245	required.
		1246
		1247	For example, to emulate how many other event libraries handle priorities,
		1248	you can associate an C<ev_idle> watcher to each such watcher, and in
		1249	the normal watcher callback, you just start the idle watcher. The real
		1250	processing is done in the idle watcher callback. This causes libev to
		1251	continously poll and process kernel event data for the watcher, but when
		1252	the lock-out case is known to be rare (which in turn is rare :), this is
		1253	workable.
		1254
		1255	Usually, however, the lock-out model implemented that way will perform
		1256	miserably under the type of load it was designed to handle. In that case,
		1257	it might be preferable to stop the real watcher before starting the
		1258	idle watcher, so the kernel will not have to process the event in case
		1259	the actual processing will be delayed for considerable time.
		1260
		1261	Here is an example of an I/O watcher that should run at a strictly lower
		1262	priority than the default, and which should only process data when no
		1263	other events are pending:
		1264
		1265	ev_idle idle; // actual processing watcher
		1266	ev_io io; // actual event watcher
		1267
		1268	static void
		1269	io_cb (EV_P_ ev_io *w, int revents)
		1270	{
		1271	// stop the I/O watcher, we received the event, but
		1272	// are not yet ready to handle it.
		1273	ev_io_stop (EV_A_ w);
		1274
		1275	// start the idle watcher to ahndle the actual event.
		1276	// it will not be executed as long as other watchers
		1277	// with the default priority are receiving events.
		1278	ev_idle_start (EV_A_ &idle);
		1279	}
		1280
		1281	static void
		1282	idle-cb (EV_P_ ev_idle *w, int revents)
		1283	{
		1284	// actual processing
		1285	read (STDIN_FILENO, ...);
		1286
		1287	// have to start the I/O watcher again, as
		1288	// we have handled the event
		1289	ev_io_start (EV_P_ &io);
		1290	}
		1291
		1292	// initialisation
		1293	ev_idle_init (&idle, idle_cb);
		1294	ev_io_init (&io, io_cb, STDIN_FILENO, EV_READ);
		1295	ev_io_start (EV_DEFAULT_ &io);
		1296
		1297	In the "real" world, it might also be beneficial to start a timer, so that
		1298	low-priority connections can not be locked out forever under load. This
		1299	enables your program to keep a lower latency for important connections
		1300	during short periods of high load, while not completely locking out less
		1301	important ones.
1189		1302
1190		1303
1191	=head1 WATCHER TYPES	1304	=head1 WATCHER TYPES
1192		1305
1193	This section describes each watcher in detail, but will not repeat	1306	This section describes each watcher in detail, but will not repeat
…		…
1582	If the timer is started but non-repeating, stop it (as if it timed out).	1695	If the timer is started but non-repeating, stop it (as if it timed out).
1583		1696
1584	If the timer is repeating, either start it if necessary (with the	1697	If the timer is repeating, either start it if necessary (with the
1585	C<repeat> value), or reset the running timer to the C<repeat> value.	1698	C<repeat> value), or reset the running timer to the C<repeat> value.
1586		1699
1587	This sounds a bit complicated, see "Be smart about timeouts", above, for a	1700	This sounds a bit complicated, see L<Be smart about timeouts>, above, for a
1588	usage example.	1701	usage example.
1589		1702
1590	=item ev_tstamp repeat [read-write]	1703	=item ev_tstamp repeat [read-write]
1591		1704
1592	The current C<repeat> value. Will be used each time the watcher times out	1705	The current C<repeat> value. Will be used each time the watcher times out
…		…
2595	event loop blocks next and before C<ev_check> watchers are being called,	2708	event loop blocks next and before C<ev_check> watchers are being called,
2596	and only in the child after the fork. If whoever good citizen calling	2709	and only in the child after the fork. If whoever good citizen calling
2597	C<ev_default_fork> cheats and calls it in the wrong process, the fork	2710	C<ev_default_fork> cheats and calls it in the wrong process, the fork
2598	handlers will be invoked, too, of course.	2711	handlers will be invoked, too, of course.
2599		2712
		2713	=head3 The special problem of life after fork - how is it possible?
		2714
		2715	Most uses of C<fork()> consist of forking, then some simple calls to ste
		2716	up/change the process environment, followed by a call to C<exec()>. This
		2717	sequence should be handled by libev without any problems.
		2718
		2719	This changes when the application actually wants to do event handling
		2720	in the child, or both parent in child, in effect "continuing" after the
		2721	fork.
		2722
		2723	The default mode of operation (for libev, with application help to detect
		2724	forks) is to duplicate all the state in the child, as would be expected
		2725	when I<either> the parent I<or> the child process continues.
		2726
		2727	When both processes want to continue using libev, then this is usually the
		2728	wrong result. In that case, usually one process (typically the parent) is
		2729	supposed to continue with all watchers in place as before, while the other
		2730	process typically wants to start fresh, i.e. without any active watchers.
		2731
		2732	The cleanest and most efficient way to achieve that with libev is to
		2733	simply create a new event loop, which of course will be "empty", and
		2734	use that for new watchers. This has the advantage of not touching more
		2735	memory than necessary, and thus avoiding the copy-on-write, and the
		2736	disadvantage of having to use multiple event loops (which do not support
		2737	signal watchers).
		2738
		2739	When this is not possible, or you want to use the default loop for
		2740	other reasons, then in the process that wants to start "fresh", call
		2741	C<ev_default_destroy ()> followed by C<ev_default_loop (...)>. Destroying
		2742	the default loop will "orphan" (not stop) all registered watchers, so you
		2743	have to be careful not to execute code that modifies those watchers. Note
		2744	also that in that case, you have to re-register any signal watchers.
		2745
2600	=head3 Watcher-Specific Functions and Data Members	2746	=head3 Watcher-Specific Functions and Data Members
2601		2747
2602	=over 4	2748	=over 4
2603		2749
2604	=item ev_fork_init (ev_signal *, callback)	2750	=item ev_fork_init (ev_signal *, callback)
…		…
3993	involves iterating over all running async watchers or all signal numbers.	4139	involves iterating over all running async watchers or all signal numbers.
3994		4140
3995	=back	4141	=back
3996		4142
3997		4143
		4144	=head1 GLOSSARY
		4145
		4146	=over 4
		4147
		4148	=item active
		4149
		4150	A watcher is active as long as it has been started (has been attached to
		4151	an event loop) but not yet stopped (disassociated from the event loop).
		4152
		4153	=item application
		4154
		4155	In this document, an application is whatever is using libev.
		4156
		4157	=item callback
		4158
		4159	The address of a function that is called when some event has been
		4160	detected. Callbacks are being passed the event loop, the watcher that
		4161	received the event, and the actual event bitset.
		4162
		4163	=item callback invocation
		4164
		4165	The act of calling the callback associated with a watcher.
		4166
		4167	=item event
		4168
		4169	A change of state of some external event, such as data now being available
		4170	for reading on a file descriptor, time having passed or simply not having
		4171	any other events happening anymore.
		4172
		4173	In libev, events are represented as single bits (such as C<EV_READ> or
		4174	C<EV_TIMEOUT>).
		4175
		4176	=item event library
		4177
		4178	A software package implementing an event model and loop.
		4179
		4180	=item event loop
		4181
		4182	An entity that handles and processes external events and converts them
		4183	into callback invocations.
		4184
		4185	=item event model
		4186
		4187	The model used to describe how an event loop handles and processes
		4188	watchers and events.
		4189
		4190	=item pending
		4191
		4192	A watcher is pending as soon as the corresponding event has been detected,
		4193	and stops being pending as soon as the watcher will be invoked or its
		4194	pending status is explicitly cleared by the application.
		4195
		4196	A watcher can be pending, but not active. Stopping a watcher also clears
		4197	its pending status.
		4198
		4199	=item real time
		4200
		4201	The physical time that is observed. It is apparently strictly monotonic :)
		4202
		4203	=item wall-clock time
		4204
		4205	The time and date as shown on clocks. Unlike real time, it can actually
		4206	be wrong and jump forwards and backwards, e.g. when the you adjust your
		4207	clock.
		4208
		4209	=item watcher
		4210
		4211	A data structure that describes interest in certain events. Watchers need
		4212	to be started (attached to an event loop) before they can receive events.
		4213
		4214	=item watcher invocation
		4215
		4216	The act of calling the callback associated with a watcher.
		4217
		4218	=back
		4219
3998	=head1 AUTHOR	4220	=head1 AUTHOR
3999		4221
4000	Marc Lehmann <libev@schmorp.de>, with repeated corrections by Mikael Magnusson.	4222	Marc Lehmann <libev@schmorp.de>, with repeated corrections by Mikael Magnusson.
4001		4223

Diff Legend

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

Comparing libev/ev.pod (file contents): Revision 1.231 by root, Wed Apr 15 19:35:53 2009 UTC vs. Revision 1.238 by root, Sat Apr 18 12:10:41 2009 UTC

Diff Legend

Comparing libev/ev.pod (file contents):
Revision 1.231 by root, Wed Apr 15 19:35:53 2009 UTC vs.
Revision 1.238 by root, Sat Apr 18 12:10:41 2009 UTC