Browse Source

*** empty log message ***

master
Marc Alexander Lehmann 14 years ago
parent
commit
d017939b24
  1. 19
      ev.3
  2. 18
      ev.html
  3. 19
      ev.pod

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

@ -6,7 +6,7 @@
<meta name="description" content="Pod documentation for libev" />
<meta name="inputfile" content="&lt;standard input&gt;" />
<meta name="outputfile" content="&lt;standard output&gt;" />
<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 &quot;file open&quot;).</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

@ -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…
Cancel
Save