mirror of /home/gitosis/repositories/libev.git
*** empty log message ***
This commit is contained in:
parent
f4e8e48096
commit
d017939b24
19
ev.3
19
ev.3
|
@ -304,6 +304,10 @@ result in some caching, there is still a syscall per such incident
|
|||
(because the fd could point to a different file description now), so its
|
||||
best to avoid that. Also, \fIdup()\fRed file descriptors might not work very
|
||||
well if you register events for both fds.
|
||||
.Sp
|
||||
Please note that epoll sometimes generates spurious notifications, so you
|
||||
need to use non-blocking I/O or other means to avoid blocking when no data
|
||||
(or space) is available.
|
||||
.ie n .IP """EVBACKEND_KQUEUE"" (value 8, most \s-1BSD\s0 clones)" 4
|
||||
.el .IP "\f(CWEVBACKEND_KQUEUE\fR (value 8, most \s-1BSD\s0 clones)" 4
|
||||
.IX Item "EVBACKEND_KQUEUE (value 8, most BSD clones)"
|
||||
|
@ -327,6 +331,10 @@ This is not implemented yet (and might never be).
|
|||
.IX Item "EVBACKEND_PORT (value 32, Solaris 10)"
|
||||
This uses the Solaris 10 port mechanism. As with everything on Solaris,
|
||||
it's really slow, but it still scales very well (O(active_fds)).
|
||||
.Sp
|
||||
Please note that solaris ports can result in a lot of spurious
|
||||
notifications, so you need to use non-blocking I/O or other means to avoid
|
||||
blocking when no data (or space) is available.
|
||||
.ie n .IP """EVBACKEND_ALL""" 4
|
||||
.el .IP "\f(CWEVBACKEND_ALL\fR" 4
|
||||
.IX Item "EVBACKEND_ALL"
|
||||
|
@ -643,6 +651,17 @@ If you must do this, then force the use of a known-to-be-good backend
|
|||
Configures an \f(CW\*(C`ev_io\*(C'\fR watcher. The fd is the file descriptor to rceeive
|
||||
events for and events is either \f(CW\*(C`EV_READ\*(C'\fR, \f(CW\*(C`EV_WRITE\*(C'\fR or \f(CW\*(C`EV_READ |
|
||||
EV_WRITE\*(C'\fR to receive the given events.
|
||||
.Sp
|
||||
Please note that most of the more scalable backend mechanisms (for example
|
||||
epoll and solaris ports) can result in spurious readyness notifications
|
||||
for file descriptors, so you practically need to use non-blocking I/O (and
|
||||
treat callback invocation as hint only), or retest separately with a safe
|
||||
interface before doing I/O (XLib can do this), or force the use of either
|
||||
\&\f(CW\*(C`EVBACKEND_SELECT\*(C'\fR or \f(CW\*(C`EVBACKEND_POLL\*(C'\fR, which don't suffer from this
|
||||
problem. Also note that it is quite easy to have your callback invoked
|
||||
when the readyness condition is no longer valid even when employing
|
||||
typical ways of handling events, so its a good idea to use non-blocking
|
||||
I/O unconditionally.
|
||||
.ie n .Sh """ev_timer"" \- relative and optionally recurring timeouts"
|
||||
.el .Sh "\f(CWev_timer\fP \- relative and optionally recurring timeouts"
|
||||
.IX Subsection "ev_timer - relative and optionally recurring timeouts"
|
||||
|
|
18
ev.html
18
ev.html
|
@ -6,7 +6,7 @@
|
|||
<meta name="description" content="Pod documentation for libev" />
|
||||
<meta name="inputfile" content="<standard input>" />
|
||||
<meta name="outputfile" content="<standard output>" />
|
||||
<meta name="created" content="Fri Nov 23 06:14:47 2007" />
|
||||
<meta name="created" content="Fri Nov 23 09:26:40 2007" />
|
||||
<meta name="generator" content="Pod::Xhtml 1.57" />
|
||||
<link rel="stylesheet" href="http://res.tst.eu/pod.css"/></head>
|
||||
<body>
|
||||
|
@ -230,6 +230,9 @@ result in some caching, there is still a syscall per such incident
|
|||
(because the fd could point to a different file description now), so its
|
||||
best to avoid that. Also, dup()ed file descriptors might not work very
|
||||
well if you register events for both fds.</p>
|
||||
<p>Please note that epoll sometimes generates spurious notifications, so you
|
||||
need to use non-blocking I/O or other means to avoid blocking when no data
|
||||
(or space) is available.</p>
|
||||
</dd>
|
||||
<dt><code>EVBACKEND_KQUEUE</code> (value 8, most BSD clones)</dt>
|
||||
<dd>
|
||||
|
@ -252,6 +255,9 @@ incident, so its best to avoid that.</p>
|
|||
<dd>
|
||||
<p>This uses the Solaris 10 port mechanism. As with everything on Solaris,
|
||||
it's really slow, but it still scales very well (O(active_fds)).</p>
|
||||
<p>Please note that solaris ports can result in a lot of spurious
|
||||
notifications, so you need to use non-blocking I/O or other means to avoid
|
||||
blocking when no data (or space) is available.</p>
|
||||
</dd>
|
||||
<dt><code>EVBACKEND_ALL</code></dt>
|
||||
<dd>
|
||||
|
@ -550,6 +556,16 @@ the same underlying "file open").</p>
|
|||
<p>Configures an <code>ev_io</code> watcher. The fd is the file descriptor to rceeive
|
||||
events for and events is either <code>EV_READ</code>, <code>EV_WRITE</code> or <code>EV_READ |
|
||||
EV_WRITE</code> to receive the given events.</p>
|
||||
<p>Please note that most of the more scalable backend mechanisms (for example
|
||||
epoll and solaris ports) can result in spurious readyness notifications
|
||||
for file descriptors, so you practically need to use non-blocking I/O (and
|
||||
treat callback invocation as hint only), or retest separately with a safe
|
||||
interface before doing I/O (XLib can do this), or force the use of either
|
||||
<code>EVBACKEND_SELECT</code> or <code>EVBACKEND_POLL</code>, which don't suffer from this
|
||||
problem. Also note that it is quite easy to have your callback invoked
|
||||
when the readyness condition is no longer valid even when employing
|
||||
typical ways of handling events, so its a good idea to use non-blocking
|
||||
I/O unconditionally.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
|
19
ev.pod
19
ev.pod
|
@ -191,6 +191,10 @@ result in some caching, there is still a syscall per such incident
|
|||
best to avoid that. Also, dup()ed file descriptors might not work very
|
||||
well if you register events for both fds.
|
||||
|
||||
Please note that epoll sometimes generates spurious notifications, so you
|
||||
need to use non-blocking I/O or other means to avoid blocking when no data
|
||||
(or space) is available.
|
||||
|
||||
=item C<EVBACKEND_KQUEUE> (value 8, most BSD clones)
|
||||
|
||||
Kqueue deserves special mention, as at the time of this writing, it
|
||||
|
@ -214,6 +218,10 @@ This is not implemented yet (and might never be).
|
|||
This uses the Solaris 10 port mechanism. As with everything on Solaris,
|
||||
it's really slow, but it still scales very well (O(active_fds)).
|
||||
|
||||
Please note that solaris ports can result in a lot of spurious
|
||||
notifications, so you need to use non-blocking I/O or other means to avoid
|
||||
blocking when no data (or space) is available.
|
||||
|
||||
=item C<EVBACKEND_ALL>
|
||||
|
||||
Try all backends (even potentially broken ones that wouldn't be tried
|
||||
|
@ -530,6 +538,17 @@ Configures an C<ev_io> watcher. The fd is the file descriptor to rceeive
|
|||
events for and events is either C<EV_READ>, C<EV_WRITE> or C<EV_READ |
|
||||
EV_WRITE> to receive the given events.
|
||||
|
||||
Please note that most of the more scalable backend mechanisms (for example
|
||||
epoll and solaris ports) can result in spurious readyness notifications
|
||||
for file descriptors, so you practically need to use non-blocking I/O (and
|
||||
treat callback invocation as hint only), or retest separately with a safe
|
||||
interface before doing I/O (XLib can do this), or force the use of either
|
||||
C<EVBACKEND_SELECT> or C<EVBACKEND_POLL>, which don't suffer from this
|
||||
problem. Also note that it is quite easy to have your callback invoked
|
||||
when the readyness condition is no longer valid even when employing
|
||||
typical ways of handling events, so its a good idea to use non-blocking
|
||||
I/O unconditionally.
|
||||
|
||||
=back
|
||||
|
||||
=head2 C<ev_timer> - relative and optionally recurring timeouts
|
||||
|
|
Loading…
Reference in New Issue