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

Comparing libev/ev.pod (file contents):
Revision 1.260 by root, Sun Jul 19 21:18:03 2009 UTC vs.
Revision 1.277 by root, Thu Dec 31 06:50:17 2009 UTC

…		…
98	=head2 FEATURES	98	=head2 FEATURES
99		99
100	Libev supports C<select>, C<poll>, the Linux-specific C<epoll>, the	100	Libev supports C<select>, C<poll>, the Linux-specific C<epoll>, the
101	BSD-specific C<kqueue> and the Solaris-specific event port mechanisms	101	BSD-specific C<kqueue> and the Solaris-specific event port mechanisms
102	for file descriptor events (C<ev_io>), the Linux C<inotify> interface	102	for file descriptor events (C<ev_io>), the Linux C<inotify> interface
103	(for C<ev_stat>), relative timers (C<ev_timer>), absolute timers	103	(for C<ev_stat>), Linux eventfd/signalfd (for faster and cleaner
104	with customised rescheduling (C<ev_periodic>), synchronous signals	104	inter-thread wakeup (C<ev_async>)/signal handling (C<ev_signal>)) relative
105	(C<ev_signal>), process status change events (C<ev_child>), and event	105	timers (C<ev_timer>), absolute timers with customised rescheduling
106	watchers dealing with the event loop mechanism itself (C<ev_idle>,	106	(C<ev_periodic>), synchronous signals (C<ev_signal>), process status
107	C<ev_embed>, C<ev_prepare> and C<ev_check> watchers) as well as	107	change events (C<ev_child>), and event watchers dealing with the event
108	file watchers (C<ev_stat>) and even limited support for fork events	108	loop mechanism itself (C<ev_idle>, C<ev_embed>, C<ev_prepare> and
109	(C<ev_fork>).	109	C<ev_check> watchers) as well as file watchers (C<ev_stat>) and even
		110	limited support for fork events (C<ev_fork>).
110		111
111	It also is quite fast (see this	112	It also is quite fast (see this
112	L<benchmark\|http://libev.schmorp.de/bench.html> comparing it to libevent	113	L<benchmark\|http://libev.schmorp.de/bench.html> comparing it to libevent
113	for example).	114	for example).
114		115
…		…
117	Libev is very configurable. In this manual the default (and most common)	118	Libev is very configurable. In this manual the default (and most common)
118	configuration will be described, which supports multiple event loops. For	119	configuration will be described, which supports multiple event loops. For
119	more info about various configuration options please have a look at	120	more info about various configuration options please have a look at
120	B<EMBED> section in this manual. If libev was configured without support	121	B<EMBED> section in this manual. If libev was configured without support
121	for multiple event loops, then all functions taking an initial argument of	122	for multiple event loops, then all functions taking an initial argument of
122	name C<loop> (which is always of type C<ev_loop *>) will not have	123	name C<loop> (which is always of type C<struct ev_loop *>) will not have
123	this argument.	124	this argument.
124		125
125	=head2 TIME REPRESENTATION	126	=head2 TIME REPRESENTATION
126		127
127	Libev represents time as a single floating point number, representing	128	Libev represents time as a single floating point number, representing
…		…
369	When this flag is specified, then libev will not attempt to use the	370	When this flag is specified, then libev will not attempt to use the
370	I<inotify> API for it's C<ev_stat> watchers. Apart from debugging and	371	I<inotify> API for it's C<ev_stat> watchers. Apart from debugging and
371	testing, this flag can be useful to conserve inotify file descriptors, as	372	testing, this flag can be useful to conserve inotify file descriptors, as
372	otherwise each loop using C<ev_stat> watchers consumes one inotify handle.	373	otherwise each loop using C<ev_stat> watchers consumes one inotify handle.
373		374
374	=item C<EVFLAG_NOSIGNALFD>	375	=item C<EVFLAG_SIGNALFD>
375		376
376	When this flag is specified, then libev will not attempt to use the	377	When this flag is specified, then libev will attempt to use the
377	I<signalfd> API for it's C<ev_signal> (and C<ev_child>) watchers. This is	378	I<signalfd> API for it's C<ev_signal> (and C<ev_child>) watchers. This API
378	probably only useful to work around any bugs in libev. Consequently, this	379	delivers signals synchronously, which makes is both faster and might make
379	flag might go away once the signalfd functionality is considered stable,	380	it possible to get the queued signal data.
380	so it's useful mostly in environment variables and not in program code.	381
		382	Signalfd will not be used by default as this changes your signal mask, and
		383	there are a lot of shoddy libraries and programs (glib's threadpool for
		384	example) that can't properly initialise their signal masks.
381		385
382	=item C<EVBACKEND_SELECT> (value 1, portable select backend)	386	=item C<EVBACKEND_SELECT> (value 1, portable select backend)
383		387
384	This is your standard select(2) backend. Not I<completely> standard, as	388	This is your standard select(2) backend. Not I<completely> standard, as
385	libev tries to roll its own fd_set with no limits on the number of fds,	389	libev tries to roll its own fd_set with no limits on the number of fds,
…		…
409		413
410	This backend maps C<EV_READ> to C<POLLIN \| POLLERR \| POLLHUP>, and	414	This backend maps C<EV_READ> to C<POLLIN \| POLLERR \| POLLHUP>, and
411	C<EV_WRITE> to C<POLLOUT \| POLLERR \| POLLHUP>.	415	C<EV_WRITE> to C<POLLOUT \| POLLERR \| POLLHUP>.
412		416
413	=item C<EVBACKEND_EPOLL> (value 4, Linux)	417	=item C<EVBACKEND_EPOLL> (value 4, Linux)
		418
		419	Use the linux-specific epoll(7) interface (for both pre- and post-2.6.9
		420	kernels).
414		421
415	For few fds, this backend is a bit little slower than poll and select,	422	For few fds, this backend is a bit little slower than poll and select,
416	but it scales phenomenally better. While poll and select usually scale	423	but it scales phenomenally better. While poll and select usually scale
417	like O(total_fds) where n is the total number of fds (or the highest fd),	424	like O(total_fds) where n is the total number of fds (or the highest fd),
418	epoll scales either O(1) or O(active_fds).	425	epoll scales either O(1) or O(active_fds).
…		…
589	as signal and child watchers) would need to be stopped manually.	596	as signal and child watchers) would need to be stopped manually.
590		597
591	In general it is not advisable to call this function except in the	598	In general it is not advisable to call this function except in the
592	rare occasion where you really need to free e.g. the signal handling	599	rare occasion where you really need to free e.g. the signal handling
593	pipe fds. If you need dynamically allocated loops it is better to use	600	pipe fds. If you need dynamically allocated loops it is better to use
594	C<ev_loop_new> and C<ev_loop_destroy>).	601	C<ev_loop_new> and C<ev_loop_destroy>.
595		602
596	=item ev_loop_destroy (loop)	603	=item ev_loop_destroy (loop)
597		604
598	Like C<ev_default_destroy>, but destroys an event loop created by an	605	Like C<ev_default_destroy>, but destroys an event loop created by an
599	earlier call to C<ev_loop_new>.	606	earlier call to C<ev_loop_new>.
…		…
703	event loop time (see C<ev_now_update>).	710	event loop time (see C<ev_now_update>).
704		711
705	=item ev_loop (loop, int flags)	712	=item ev_loop (loop, int flags)
706		713
707	Finally, this is it, the event handler. This function usually is called	714	Finally, this is it, the event handler. This function usually is called
708	after you initialised all your watchers and you want to start handling	715	after you have initialised all your watchers and you want to start
709	events.	716	handling events.
710		717
711	If the flags argument is specified as C<0>, it will not return until	718	If the flags argument is specified as C<0>, it will not return until
712	either no event watchers are active anymore or C<ev_unloop> was called.	719	either no event watchers are active anymore or C<ev_unloop> was called.
713		720
714	Please note that an explicit C<ev_unloop> is usually better than	721	Please note that an explicit C<ev_unloop> is usually better than
…		…
788		795
789	Ref/unref can be used to add or remove a reference count on the event	796	Ref/unref can be used to add or remove a reference count on the event
790	loop: Every watcher keeps one reference, and as long as the reference	797	loop: Every watcher keeps one reference, and as long as the reference
791	count is nonzero, C<ev_loop> will not return on its own.	798	count is nonzero, C<ev_loop> will not return on its own.
792		799
793	If you have a watcher you never unregister that should not keep C<ev_loop>	800	This is useful when you have a watcher that you never intend to
794	from returning, call ev_unref() after starting, and ev_ref() before	801	unregister, but that nevertheless should not keep C<ev_loop> from
		802	returning. In such a case, call C<ev_unref> after starting, and C<ev_ref>
795	stopping it.	803	before stopping it.
796		804
797	As an example, libev itself uses this for its internal signal pipe: It	805	As an example, libev itself uses this for its internal signal pipe: It
798	is not visible to the libev user and should not keep C<ev_loop> from	806	is not visible to the libev user and should not keep C<ev_loop> from
799	exiting if no event watchers registered by it are active. It is also an	807	exiting if no event watchers registered by it are active. It is also an
800	excellent way to do this for generic recurring timers or from within	808	excellent way to do this for generic recurring timers or from within
…		…
915		923
916	While event loop modifications are allowed between invocations of	924	While event loop modifications are allowed between invocations of
917	C<release> and C<acquire> (that's their only purpose after all), no	925	C<release> and C<acquire> (that's their only purpose after all), no
918	modifications done will affect the event loop, i.e. adding watchers will	926	modifications done will affect the event loop, i.e. adding watchers will
919	have no effect on the set of file descriptors being watched, or the time	927	have no effect on the set of file descriptors being watched, or the time
920	waited. USe an C<ev_async> watcher to wake up C<ev_loop> when you want it	928	waited. Use an C<ev_async> watcher to wake up C<ev_loop> when you want it
921	to take note of any changes you made.	929	to take note of any changes you made.
922		930
923	In theory, threads executing C<ev_loop> will be async-cancel safe between	931	In theory, threads executing C<ev_loop> will be async-cancel safe between
924	invocations of C<release> and C<acquire>.	932	invocations of C<release> and C<acquire>.
925		933
…		…
1122		1130
1123	ev_io w;	1131	ev_io w;
1124	ev_init (&w, my_cb);	1132	ev_init (&w, my_cb);
1125	ev_io_set (&w, STDIN_FILENO, EV_READ);	1133	ev_io_set (&w, STDIN_FILENO, EV_READ);
1126		1134
1127	=item C<ev_TYPE_set> (ev_TYPE *, [args])	1135	=item C<ev_TYPE_set> (ev_TYPE *watcher, [args])
1128		1136
1129	This macro initialises the type-specific parts of a watcher. You need to	1137	This macro initialises the type-specific parts of a watcher. You need to
1130	call C<ev_init> at least once before you call this macro, but you can	1138	call C<ev_init> at least once before you call this macro, but you can
1131	call C<ev_TYPE_set> any number of times. You must not, however, call this	1139	call C<ev_TYPE_set> any number of times. You must not, however, call this
1132	macro on a watcher that is active (it can be pending, however, which is a	1140	macro on a watcher that is active (it can be pending, however, which is a
…		…
1145		1153
1146	Example: Initialise and set an C<ev_io> watcher in one step.	1154	Example: Initialise and set an C<ev_io> watcher in one step.
1147		1155
1148	ev_io_init (&w, my_cb, STDIN_FILENO, EV_READ);	1156	ev_io_init (&w, my_cb, STDIN_FILENO, EV_READ);
1149		1157
1150	=item C<ev_TYPE_start> (loop , ev_TYPE watcher)	1158	=item C<ev_TYPE_start> (loop, ev_TYPE *watcher)
1151		1159
1152	Starts (activates) the given watcher. Only active watchers will receive	1160	Starts (activates) the given watcher. Only active watchers will receive
1153	events. If the watcher is already active nothing will happen.	1161	events. If the watcher is already active nothing will happen.
1154		1162
1155	Example: Start the C<ev_io> watcher that is being abused as example in this	1163	Example: Start the C<ev_io> watcher that is being abused as example in this
1156	whole section.	1164	whole section.
1157		1165
1158	ev_io_start (EV_DEFAULT_UC, &w);	1166	ev_io_start (EV_DEFAULT_UC, &w);
1159		1167
1160	=item C<ev_TYPE_stop> (loop , ev_TYPE watcher)	1168	=item C<ev_TYPE_stop> (loop, ev_TYPE *watcher)
1161		1169
1162	Stops the given watcher if active, and clears the pending status (whether	1170	Stops the given watcher if active, and clears the pending status (whether
1163	the watcher was active or not).	1171	the watcher was active or not).
1164		1172
1165	It is possible that stopped watchers are pending - for example,	1173	It is possible that stopped watchers are pending - for example,
…		…
1190	=item ev_cb_set (ev_TYPE *watcher, callback)	1198	=item ev_cb_set (ev_TYPE *watcher, callback)
1191		1199
1192	Change the callback. You can change the callback at virtually any time	1200	Change the callback. You can change the callback at virtually any time
1193	(modulo threads).	1201	(modulo threads).
1194		1202
1195	=item ev_set_priority (ev_TYPE *watcher, priority)	1203	=item ev_set_priority (ev_TYPE *watcher, int priority)
1196		1204
1197	=item int ev_priority (ev_TYPE *watcher)	1205	=item int ev_priority (ev_TYPE *watcher)
1198		1206
1199	Set and query the priority of the watcher. The priority is a small	1207	Set and query the priority of the watcher. The priority is a small
1200	integer between C<EV_MAXPRI> (default: C<2>) and C<EV_MINPRI>	1208	integer between C<EV_MAXPRI> (default: C<2>) and C<EV_MINPRI>
…		…
1231	returns its C<revents> bitset (as if its callback was invoked). If the	1239	returns its C<revents> bitset (as if its callback was invoked). If the
1232	watcher isn't pending it does nothing and returns C<0>.	1240	watcher isn't pending it does nothing and returns C<0>.
1233		1241
1234	Sometimes it can be useful to "poll" a watcher instead of waiting for its	1242	Sometimes it can be useful to "poll" a watcher instead of waiting for its
1235	callback to be invoked, which can be accomplished with this function.	1243	callback to be invoked, which can be accomplished with this function.
		1244
		1245	=item ev_feed_event (loop, ev_TYPE *watcher, int revents)
		1246
		1247	Feeds the given event set into the event loop, as if the specified event
		1248	had happened for the specified watcher (which must be a pointer to an
		1249	initialised but not necessarily started event watcher). Obviously you must
		1250	not free the watcher as long as it has pending events.
		1251
		1252	Stopping the watcher, letting libev invoke it, or calling
		1253	C<ev_clear_pending> will clear the pending event, even if the watcher was
		1254	not started in the first place.
		1255
		1256	See also C<ev_feed_fd_event> and C<ev_feed_signal_event> for related
		1257	functions that do not need a watcher.
1236		1258
1237	=back	1259	=back
1238		1260
1239		1261
1240	=head2 ASSOCIATING CUSTOM DATA WITH A WATCHER	1262	=head2 ASSOCIATING CUSTOM DATA WITH A WATCHER
…		…
1836	C<repeat> value), or reset the running timer to the C<repeat> value.	1858	C<repeat> value), or reset the running timer to the C<repeat> value.
1837		1859
1838	This sounds a bit complicated, see L<Be smart about timeouts>, above, for a	1860	This sounds a bit complicated, see L<Be smart about timeouts>, above, for a
1839	usage example.	1861	usage example.
1840		1862
1841	=item ev_timer_remaining (loop, ev_timer *)	1863	=item ev_tstamp ev_timer_remaining (loop, ev_timer *)
1842		1864
1843	Returns the remaining time until a timer fires. If the timer is active,	1865	Returns the remaining time until a timer fires. If the timer is active,
1844	then this time is relative to the current event loop time, otherwise it's	1866	then this time is relative to the current event loop time, otherwise it's
1845	the timeout value currently configured.	1867	the timeout value currently configured.
1846		1868
…		…
2107		2129
2108	When the first watcher gets started will libev actually register something	2130	When the first watcher gets started will libev actually register something
2109	with the kernel (thus it coexists with your own signal handlers as long as	2131	with the kernel (thus it coexists with your own signal handlers as long as
2110	you don't register any with libev for the same signal).	2132	you don't register any with libev for the same signal).
2111		2133
2112	Both the signal mask state (C<sigprocmask>) and the signal handler state
2113	(C<sigaction>) are unspecified after starting a signal watcher (and after
2114	sotpping it again), that is, libev might or might not block the signal,
2115	and might or might not set or restore the installed signal handler.
2116
2117	If possible and supported, libev will install its handlers with	2134	If possible and supported, libev will install its handlers with
2118	C<SA_RESTART> (or equivalent) behaviour enabled, so system calls should	2135	C<SA_RESTART> (or equivalent) behaviour enabled, so system calls should
2119	not be unduly interrupted. If you have a problem with system calls getting	2136	not be unduly interrupted. If you have a problem with system calls getting
2120	interrupted by signals you can block all signals in an C<ev_check> watcher	2137	interrupted by signals you can block all signals in an C<ev_check> watcher
2121	and unblock them in an C<ev_prepare> watcher.	2138	and unblock them in an C<ev_prepare> watcher.
		2139
		2140	=head3 The special problem of inheritance over fork/execve/pthread_create
		2141
		2142	Both the signal mask (C<sigprocmask>) and the signal disposition
		2143	(C<sigaction>) are unspecified after starting a signal watcher (and after
		2144	stopping it again), that is, libev might or might not block the signal,
		2145	and might or might not set or restore the installed signal handler.
		2146
		2147	While this does not matter for the signal disposition (libev never
		2148	sets signals to C<SIG_IGN>, so handlers will be reset to C<SIG_DFL> on
		2149	C<execve>), this matters for the signal mask: many programs do not expect
		2150	certain signals to be blocked.
		2151
		2152	This means that before calling C<exec> (from the child) you should reset
		2153	the signal mask to whatever "default" you expect (all clear is a good
		2154	choice usually).
		2155
		2156	The simplest way to ensure that the signal mask is reset in the child is
		2157	to install a fork handler with C<pthread_atfork> that resets it. That will
		2158	catch fork calls done by libraries (such as the libc) as well.
		2159
		2160	In current versions of libev, the signal will not be blocked indefinitely
		2161	unless you use the C<signalfd> API (C<EV_SIGNALFD>). While this reduces
		2162	the window of opportunity for problems, it will not go away, as libev
		2163	I<has> to modify the signal mask, at least temporarily.
		2164
		2165	So I can't stress this enough I<if you do not reset your signal mask
		2166	when you expect it to be empty, you have a race condition in your
		2167	program>. This is not a libev-specific thing, this is true for most event
		2168	libraries.
2122		2169
2123	=head3 Watcher-Specific Functions and Data Members	2170	=head3 Watcher-Specific Functions and Data Members
2124		2171
2125	=over 4	2172	=over 4
2126		2173
…		…
2943	=head3 Queueing	2990	=head3 Queueing
2944		2991
2945	C<ev_async> does not support queueing of data in any way. The reason	2992	C<ev_async> does not support queueing of data in any way. The reason
2946	is that the author does not know of a simple (or any) algorithm for a	2993	is that the author does not know of a simple (or any) algorithm for a
2947	multiple-writer-single-reader queue that works in all cases and doesn't	2994	multiple-writer-single-reader queue that works in all cases and doesn't
2948	need elaborate support such as pthreads.	2995	need elaborate support such as pthreads or unportable memory access
		2996	semantics.
2949		2997
2950	That means that if you want to queue data, you have to provide your own	2998	That means that if you want to queue data, you have to provide your own
2951	queue. But at least I can tell you how to implement locking around your	2999	queue. But at least I can tell you how to implement locking around your
2952	queue:	3000	queue:
2953		3001
…		…
3111	/* doh, nothing entered */;	3159	/* doh, nothing entered */;
3112	}	3160	}
3113		3161
3114	ev_once (STDIN_FILENO, EV_READ, 10., stdin_ready, 0);	3162	ev_once (STDIN_FILENO, EV_READ, 10., stdin_ready, 0);
3115		3163
3116	=item ev_feed_event (struct ev_loop , watcher , int revents)
3117
3118	Feeds the given event set into the event loop, as if the specified event
3119	had happened for the specified watcher (which must be a pointer to an
3120	initialised but not necessarily started event watcher).
3121
3122	=item ev_feed_fd_event (struct ev_loop *, int fd, int revents)	3164	=item ev_feed_fd_event (loop, int fd, int revents)
3123		3165
3124	Feed an event on the given fd, as if a file descriptor backend detected	3166	Feed an event on the given fd, as if a file descriptor backend detected
3125	the given events it.	3167	the given events it.
3126		3168
3127	=item ev_feed_signal_event (struct ev_loop *loop, int signum)	3169	=item ev_feed_signal_event (loop, int signum)
3128		3170
3129	Feed an event as if the given signal occurred (C<loop> must be the default	3171	Feed an event as if the given signal occurred (C<loop> must be the default
3130	loop!).	3172	loop!).
3131		3173
3132	=back	3174	=back
…		…
3212		3254
3213	=over 4	3255	=over 4
3214		3256
3215	=item ev::TYPE::TYPE ()	3257	=item ev::TYPE::TYPE ()
3216		3258
3217	=item ev::TYPE::TYPE (struct ev_loop *)	3259	=item ev::TYPE::TYPE (loop)
3218		3260
3219	=item ev::TYPE::~TYPE	3261	=item ev::TYPE::~TYPE
3220		3262
3221	The constructor (optionally) takes an event loop to associate the watcher	3263	The constructor (optionally) takes an event loop to associate the watcher
3222	with. If it is omitted, it will use C<EV_DEFAULT>.	3264	with. If it is omitted, it will use C<EV_DEFAULT>.
…		…
3299	Example: Use a plain function as callback.	3341	Example: Use a plain function as callback.
3300		3342
3301	static void io_cb (ev::io &w, int revents) { }	3343	static void io_cb (ev::io &w, int revents) { }
3302	iow.set <io_cb> ();	3344	iow.set <io_cb> ();
3303		3345
3304	=item w->set (struct ev_loop *)	3346	=item w->set (loop)
3305		3347
3306	Associates a different C<struct ev_loop> with this watcher. You can only	3348	Associates a different C<struct ev_loop> with this watcher. You can only
3307	do this when the watcher is inactive (and not pending either).	3349	do this when the watcher is inactive (and not pending either).
3308		3350
3309	=item w->set ([arguments])	3351	=item w->set ([arguments])
…		…
3406	=item Ocaml	3448	=item Ocaml
3407		3449
3408	Erkki Seppala has written Ocaml bindings for libev, to be found at	3450	Erkki Seppala has written Ocaml bindings for libev, to be found at
3409	L<http://modeemi.cs.tut.fi/~flux/software/ocaml-ev/>.	3451	L<http://modeemi.cs.tut.fi/~flux/software/ocaml-ev/>.
3410		3452
		3453	=item Lua
		3454
		3455	Brian Maher has written a partial interface to libev
		3456	for lua (only C<ev_io> and C<ev_timer>), to be found at
		3457	L<http://github.com/brimworks/lua-ev>.
		3458
3411	=back	3459	=back
3412		3460
3413		3461
3414	=head1 MACRO MAGIC	3462	=head1 MACRO MAGIC
3415		3463
…		…
3581	keeps libev from including F<config.h>, and it also defines dummy	3629	keeps libev from including F<config.h>, and it also defines dummy
3582	implementations for some libevent functions (such as logging, which is not	3630	implementations for some libevent functions (such as logging, which is not
3583	supported). It will also not define any of the structs usually found in	3631	supported). It will also not define any of the structs usually found in
3584	F<event.h> that are not directly supported by the libev core alone.	3632	F<event.h> that are not directly supported by the libev core alone.
3585		3633
3586	In stanbdalone mode, libev will still try to automatically deduce the	3634	In standalone mode, libev will still try to automatically deduce the
3587	configuration, but has to be more conservative.	3635	configuration, but has to be more conservative.
3588		3636
3589	=item EV_USE_MONOTONIC	3637	=item EV_USE_MONOTONIC
3590		3638
3591	If defined to be C<1>, libev will try to detect the availability of the	3639	If defined to be C<1>, libev will try to detect the availability of the
…		…
3656	be used is the winsock select). This means that it will call	3704	be used is the winsock select). This means that it will call
3657	C<_get_osfhandle> on the fd to convert it to an OS handle. Otherwise,	3705	C<_get_osfhandle> on the fd to convert it to an OS handle. Otherwise,
3658	it is assumed that all these functions actually work on fds, even	3706	it is assumed that all these functions actually work on fds, even
3659	on win32. Should not be defined on non-win32 platforms.	3707	on win32. Should not be defined on non-win32 platforms.
3660		3708
3661	=item EV_FD_TO_WIN32_HANDLE	3709	=item EV_FD_TO_WIN32_HANDLE(fd)
3662		3710
3663	If C<EV_SELECT_IS_WINSOCKET> is enabled, then libev needs a way to map	3711	If C<EV_SELECT_IS_WINSOCKET> is enabled, then libev needs a way to map
3664	file descriptors to socket handles. When not defining this symbol (the	3712	file descriptors to socket handles. When not defining this symbol (the
3665	default), then libev will call C<_get_osfhandle>, which is usually	3713	default), then libev will call C<_get_osfhandle>, which is usually
3666	correct. In some cases, programs use their own file descriptor management,	3714	correct. In some cases, programs use their own file descriptor management,
3667	in which case they can provide this function to map fds to socket handles.	3715	in which case they can provide this function to map fds to socket handles.
		3716
		3717	=item EV_WIN32_HANDLE_TO_FD(handle)
		3718
		3719	If C<EV_SELECT_IS_WINSOCKET> then libev maps handles to file descriptors
		3720	using the standard C<_open_osfhandle> function. For programs implementing
		3721	their own fd to handle mapping, overwriting this function makes it easier
		3722	to do so. This can be done by defining this macro to an appropriate value.
		3723
		3724	=item EV_WIN32_CLOSE_FD(fd)
		3725
		3726	If programs implement their own fd to handle mapping on win32, then this
		3727	macro can be used to override the C<close> function, useful to unregister
		3728	file descriptors again. Note that the replacement function has to close
		3729	the underlying OS handle.
3668		3730
3669	=item EV_USE_POLL	3731	=item EV_USE_POLL
3670		3732
3671	If defined to be C<1>, libev will compile in support for the C<poll>(2)	3733	If defined to be C<1>, libev will compile in support for the C<poll>(2)
3672	backend. Otherwise it will be enabled on non-win32 platforms. It	3734	backend. Otherwise it will be enabled on non-win32 platforms. It

Diff Legend

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

Comparing libev/ev.pod (file contents): Revision 1.260 by root, Sun Jul 19 21:18:03 2009 UTC vs. Revision 1.277 by root, Thu Dec 31 06:50:17 2009 UTC

Diff Legend

Comparing libev/ev.pod (file contents):
Revision 1.260 by root, Sun Jul 19 21:18:03 2009 UTC vs.
Revision 1.277 by root, Thu Dec 31 06:50:17 2009 UTC