LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "David Schwartz" <davids@webmaster.com>
To: "Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>
Subject: RE: O_NONBLOCK setting "leak" outside of a process??
Date: Sat, 3 Feb 2007 23:56:44 -0800	[thread overview]
Message-ID: <MDEHLPKNGKAHNMBLJOLKEELOBFAC.davids@webmaster.com> (raw)
In-Reply-To: <200702040222.13337.vda.linux@googlemail.com>


> Easy. O_NONBLOCK should only affect whether read/write blocks or
> returns EAGAIN. It's logical for this setting to be per-process.

Sadly, that's not what POSIX says. POSIX says that 'dup' and 'fork' create
two references to the same file description and that O_NONBLOCK is a
per-file-description flag. So such an implementation would not be
POSIX-conforming.

> Currently changing O_NONBLOCK on stdin/out/err affects other,
> possibly unrelated processes - they don't expect that *their*
> reads/writes will start returning EAGAIN!

Then they're broken. Sorry, that's just the way it is. Code should always
correctly handle defined error codes. I agree that it's unexpected and
unfortunate, but you have to code defensively.

*Every* blocking fd operation should be followed by a check to see if the
operation failed, succeeded, or partially succeeded. If it partially
succeeded, it needs to be continued. If it failed, you need to check if the
error is fatal or transient. If transient, you need to back off and retry.
It has, sadly, always been this way. (Programs can get signals, debuggers
can interrupt a system call, the unexpected happens.)

> Worse, it cannot be worked around by dup() because duped fds
> are still sharing O_NONBLOCK. How can I work around this?

If this causes your code a problem, your code is broken. What does your code
currently do if it gets a non-fatal error from a blocking operation? If it
does anything other than back off and retry, it's mishandling the condition.

It is also an error to change the modes on an inherited file descriptor
unless you know for a fact that this is what the program that gave you the
file descriptor expects you to do (or that it has relinquished that
descriptor). So it takes two bugs to cause this problem.

I agree that the world might have been a better place had this been thought
about from the beginning.

DS



  reply	other threads:[~2007-02-04  7:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-27 20:52 Denis Vlasenko
2007-01-30  3:40 ` Philippe Troin
2007-02-01 23:00   ` Denis Vlasenko
2007-02-01 23:15     ` Philippe Troin
2007-02-02 12:10       ` Roland Kuhn
2007-02-02 13:48         ` Guillaume Chazarain
2007-02-02 15:04           ` Roland Kuhn
2007-02-02 18:59             ` Philippe Troin
2007-02-05 10:49               ` bert hubert
2007-02-04  0:55         ` David Schwartz
2007-02-04  1:22           ` Denis Vlasenko
2007-02-04  7:56             ` David Schwartz [this message]
2007-02-04 20:11               ` Michael Tokarev
2007-02-04 21:08                 ` David Schwartz

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=MDEHLPKNGKAHNMBLJOLKEELOBFAC.davids@webmaster.com \
    --to=davids@webmaster.com \
    --cc=linux-kernel@vger.kernel.org \
    --subject='RE: O_NONBLOCK setting "leak" outside of a process??' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).