The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: "Michael Kerrisk" <mtk.manpages@googlemail.com>
To: 7eggert@gmx.de
Cc: "Davide Libenzi" <davidel@xmailserver.org>,
	"Pierre Habouzit" <madcoder@debian.org>,
	lkml <linux-kernel@vger.kernel.org>,
	"Eric Dumazet" <dada1@cosmosbay.com>,
	"Marc Lehmann" <schmorp@schmorp.de>,
	"David Schwartz" <davids@webmaster.com>
Subject: Re: epoll and shared fd's
Date: Thu, 28 Feb 2008 13:10:44 +0100	[thread overview]
Message-ID: <cfd18e0f0802280410wccefb42ja66a2f4ee7513183@mail.gmail.com> (raw)
In-Reply-To: <E1JU4Lu-0000mn-H2@be1.7eggert.dyndns.org>

On Tue, Feb 26, 2008 at 7:16 PM, Bodo Eggert <7eggert@gmx.de> wrote:
> Michael Kerrisk <mtk.manpages@googlemail.com> wrote:
>
>  > a) I did a
>  >
>  > s/internal kernel handle/open file description/
>  >
>  > since that is the POSIX term for the internal handle.
>  >
>  > b) It seems to me that you text doesn't quite make the point explicit
>  > enough.  I've tried to rewrite it; could you please check:
>  >
>  >        A6     Yes, but be aware of the following point.  A  file
>  >               descriptor is a reference to an open file descrip-
>  >               tion (see  open(2)).   Whenever  a  descriptor  is
>  >               duplicated  via dup(2), dup2(2), fcntl(2) F_DUPFD,
>  >               or fork(2), a new file descriptor referring to the
>  >               same  open  file  description is created.  An open
>  >               file description continues to exist until all file
>  >               descriptors referring to it have been closed.  The
>  >               epoll  interface  automatically  removes  a   file
>  >               descriptor  from  an  epoll set only after all the
>  >               file descriptors referring to the underlying  open
>  >               file  handle  have  been  closed.  This means that
>  >               even after a file descriptor that is  part  of  an
>  >               epoll  set has been closed, events may be reported
>  >               for that file descriptor if other file descriptors
>  >               referring  to the same underlying file description
>  >               remain open.
>  >
>  > Does that seem okay?  I plan to include the text in man-pages-2.79.
>
>  It's hard to read for me, and probably very hard to read for others.

Bodo,

I'm just reviewing this text, trying to see if I can improve it.  At
the moment, I'm a little stuck.  can you say a little more about why
you find it hard to read?  that may help me improve it.

Cheers,

Michael


-- 
Michael Kerrisk
Maintainer of the Linux man-pages project
http://www.kernel.org/doc/man-pages/
Want to report a man-pages bug?  Look here:
http://www.kernel.org/doc/man-pages/reporting_bugs.html

  reply	other threads:[~2008-02-28 12:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <9MZLT-1YO-33@gated-at.bofh.it>
     [not found] ` <9N6Ng-5tn-21@gated-at.bofh.it>
     [not found]   ` <9P5WE-33i-11@gated-at.bofh.it>
     [not found]     ` <9Pk9l-1KA-1@gated-at.bofh.it>
     [not found]       ` <9PNNZ-b0-5@gated-at.bofh.it>
     [not found]         ` <a19Lb-1F0-13@gated-at.bofh.it>
     [not found]           ` <a19Lb-1F0-11@gated-at.bofh.it>
2008-02-26 18:16             ` epoll and shared fd's Bodo Eggert
2008-02-28 12:10               ` Michael Kerrisk [this message]
2008-02-28 19:17                 ` Bodo Eggert
2008-02-28 19:30                   ` Davide Libenzi
2008-02-28 13:53               ` Valdis.Kletnieks
2008-02-28 15:08                 ` Michael Kerrisk
2008-02-28 19:27                 ` Davide Libenzi
2008-01-18 13:43 Pierre Habouzit
2008-01-18 21:10 ` Davide Libenzi
2008-01-24  8:40   ` Pierre Habouzit
2008-01-24 23:57     ` Davide Libenzi
2008-01-26  7:37       ` Michael Kerrisk
     [not found]         ` <Pine.LNX.4.64.0801261308270.10472@alien.or.mcafeemobile.com>
2008-02-26 15:13           ` Michael Kerrisk
2008-02-26 19:04             ` Davide Libenzi
2008-02-26 19:14               ` Michael Kerrisk
2008-02-26 19:31                 ` Davide Libenzi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cfd18e0f0802280410wccefb42ja66a2f4ee7513183@mail.gmail.com \
    --to=mtk.manpages@googlemail.com \
    --cc=7eggert@gmx.de \
    --cc=dada1@cosmosbay.com \
    --cc=davidel@xmailserver.org \
    --cc=davids@webmaster.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=madcoder@debian.org \
    --cc=schmorp@schmorp.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox