summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--ev.324
-rw-r--r--ev.html31
-rw-r--r--ev.pod22
3 files changed, 74 insertions, 3 deletions
diff --git a/ev.3 b/ev.3
index 4f3bfef..82d8e9b 100644
--- a/ev.3
+++ b/ev.3
@@ -129,7 +129,7 @@
.\" ========================================================================
.\"
.IX Title ""<STANDARD INPUT>" 1"
-.TH "<STANDARD INPUT>" 1 "2007-12-09" "perl v5.8.8" "User Contributed Perl Documentation"
+.TH "<STANDARD INPUT>" 1 "2007-12-12" "perl v5.8.8" "User Contributed Perl Documentation"
.SH "NAME"
libev \- a high performance full\-featured event loop written in C
.SH "SYNOPSIS"
@@ -1067,6 +1067,28 @@ play around with an Xlib connection), then you have to seperately re-test
whether a file descriptor is really ready with a known-to-be good interface
such as poll (fortunately in our Xlib example, Xlib already does this on
its own, so its quite safe to use).
+.PP
+\fIThe special problem of disappearing file descriptors\fR
+.IX Subsection "The special problem of disappearing file descriptors"
+.PP
+Some backends (e.g kqueue, epoll) need to be told about closing a file
+descriptor (either by calling \f(CW\*(C`close\*(C'\fR explicitly or by any other means,
+such as \f(CW\*(C`dup\*(C'\fR). The reason is that you register interest in some file
+descriptor, but when it goes away, the operating system will silently drop
+this interest. If another file descriptor with the same number then is
+registered with libev, there is no efficient way to see that this is, in
+fact, a different file descriptor.
+.PP
+To avoid having to explicitly tell libev about such cases, libev follows
+the following policy: Each time \f(CW\*(C`ev_io_set\*(C'\fR is being called, libev
+will assume that this is potentially a new file descriptor, otherwise
+it is assumed that the file descriptor stays the same. That means that
+you \fIhave\fR to call \f(CW\*(C`ev_io_set\*(C'\fR (or \f(CW\*(C`ev_io_init\*(C'\fR) when you change the
+descriptor even if the file descriptor number itself did not change.
+.PP
+This is how one would do it normally anyway, the important point is that
+the libev application should not optimise around libev but should leave
+optimisations to libev.
.IP "ev_io_init (ev_io *, callback, int fd, int events)" 4
.IX Item "ev_io_init (ev_io *, callback, int fd, int events)"
.PD 0
diff --git a/ev.html b/ev.html
index f63538f..21f24d5 100644
--- a/ev.html
+++ b/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="Sun Dec 9 20:47:27 2007" />
+ <meta name="created" content="Wed Dec 12 05:53:55 2007" />
<meta name="generator" content="Pod::Xhtml 1.57" />
<link rel="stylesheet" href="http://res.tst.eu/pod.css"/></head>
<body>
@@ -29,7 +29,10 @@
</ul>
</li>
<li><a href="#WATCHER_TYPES">WATCHER TYPES</a>
-<ul><li><a href="#code_ev_io_code_is_this_file_descrip"><code>ev_io</code> - is this file descriptor readable or writable?</a></li>
+<ul><li><a href="#code_ev_io_code_is_this_file_descrip"><code>ev_io</code> - is this file descriptor readable or writable?</a>
+<ul><li><a href="#The_special_problem_of_disappearing_">The special problem of disappearing file descriptors</a></li>
+</ul>
+</li>
<li><a href="#code_ev_timer_code_relative_and_opti"><code>ev_timer</code> - relative and optionally repeating timeouts</a></li>
<li><a href="#code_ev_periodic_code_to_cron_or_not"><code>ev_periodic</code> - to cron or not to cron?</a></li>
<li><a href="#code_ev_signal_code_signal_me_when_a"><code>ev_signal</code> - signal me when a signal gets signalled!</a></li>
@@ -943,6 +946,30 @@ play around with an Xlib connection), then you have to seperately re-test
whether a file descriptor is really ready with a known-to-be good interface
such as poll (fortunately in our Xlib example, Xlib already does this on
its own, so its quite safe to use).</p>
+
+</div>
+<h3 id="The_special_problem_of_disappearing_">The special problem of disappearing file descriptors</h3>
+<div id="The_special_problem_of_disappearing_-2">
+<p>Some backends (e.g kqueue, epoll) need to be told about closing a file
+descriptor (either by calling <code>close</code> explicitly or by any other means,
+such as <code>dup</code>). The reason is that you register interest in some file
+descriptor, but when it goes away, the operating system will silently drop
+this interest. If another file descriptor with the same number then is
+registered with libev, there is no efficient way to see that this is, in
+fact, a different file descriptor.</p>
+<p>To avoid having to explicitly tell libev about such cases, libev follows
+the following policy: Each time <code>ev_io_set</code> is being called, libev
+will assume that this is potentially a new file descriptor, otherwise
+it is assumed that the file descriptor stays the same. That means that
+you <i>have</i> to call <code>ev_io_set</code> (or <code>ev_io_init</code>) when you change the
+descriptor even if the file descriptor number itself did not change.</p>
+<p>This is how one would do it normally anyway, the important point is that
+the libev application should not optimise around libev but should leave
+optimisations to libev.</p>
+
+
+
+
<dl>
<dt>ev_io_init (ev_io *, callback, int fd, int events)</dt>
<dt>ev_io_set (ev_io *, int fd, int events)</dt>
diff --git a/ev.pod b/ev.pod
index 063c01d..ab57ffb 100644
--- a/ev.pod
+++ b/ev.pod
@@ -913,6 +913,28 @@ whether a file descriptor is really ready with a known-to-be good interface
such as poll (fortunately in our Xlib example, Xlib already does this on
its own, so its quite safe to use).
+=head3 The special problem of disappearing file descriptors
+
+Some backends (e.g kqueue, epoll) need to be told about closing a file
+descriptor (either by calling C<close> explicitly or by any other means,
+such as C<dup>). The reason is that you register interest in some file
+descriptor, but when it goes away, the operating system will silently drop
+this interest. If another file descriptor with the same number then is
+registered with libev, there is no efficient way to see that this is, in
+fact, a different file descriptor.
+
+To avoid having to explicitly tell libev about such cases, libev follows
+the following policy: Each time C<ev_io_set> is being called, libev
+will assume that this is potentially a new file descriptor, otherwise
+it is assumed that the file descriptor stays the same. That means that
+you I<have> to call C<ev_io_set> (or C<ev_io_init>) when you change the
+descriptor even if the file descriptor number itself did not change.
+
+This is how one would do it normally anyway, the important point is that
+the libev application should not optimise around libev but should leave
+optimisations to libev.
+
+
=over 4
=item ev_io_init (ev_io *, callback, int fd, int events)