From 363b337b90b2575d2cc5253af2ffe6afa0d3eb72 Mon Sep 17 00:00:00 2001 From: root Date: Wed, 12 Dec 2007 04:53:58 +0000 Subject: [PATCH] *** empty log message *** --- ev.3 | 24 +++++++++++++++++++++++- ev.html | 31 +++++++++++++++++++++++++++++-- ev.pod | 22 ++++++++++++++++++++++ 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 """ 1" -.TH "" 1 "2007-12-09" "perl v5.8.8" "User Contributed Perl Documentation" +.TH "" 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 @@ - + @@ -29,7 +29,10 @@
  • WATCHER TYPES -
    • ev_io - is this file descriptor readable or writable?
      • +
      • ev_io - is this file descriptor readable or writable? + +
      • ev_timer - relative and optionally repeating timeouts
      • ev_periodic - to cron or not to cron?
      • ev_signal - signal me when a signal gets signalled!
        • @@ -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).

        + + +

        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 close explicitly or by any other means, +such as 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 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 have to call ev_io_set (or 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.

        + + + +
        ev_io_init (ev_io *, callback, int fd, int events)
        ev_io_set (ev_io *, int fd, int events)
        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 explicitly or by any other means, +such as C). 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 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 to call C (or C) 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) -- 2.43.0