Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.os.linux.development.apps > #694

Re: Linux O_NONBLOCK bug/ quirk

From Rainer Weikusat <rweikusat@mobileactivedefense.com>
Newsgroups comp.os.linux.development.apps, comp.unix.programmer
Subject Re: Linux O_NONBLOCK bug/ quirk
Followup-To comp.unix.programmer
Date 2014-04-16 13:36 +0100
Message-ID <87y4z5tpsa.fsf@sable.mobileactivedefense.com> (permalink)
References <878urvu0gx.fsf@sable.mobileactivedefense.com> <lh4vnk$bdu$1@dont-email.me> <877g6pv6tc.fsf@sable.mobileactivedefense.com>

Cross-posted to 2 groups.

Followups directed to: comp.unix.programmer

Show all headers | View raw


Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:

> Lusotec <nomail@nomail.not> writes:
>
> [demonstration of Linux bug]
>
>> a fcntl must affect a already running operations. I think this 
>> is very problematic.
>
> NB: This is crossposted to comp.unix.programmer with a followup-to set
> as it is (in my opinion) mostly about POSIX/ UNIX(*) implementation
> quirks.
>
> NB^2: This has been tested on Linux 3.2.9 without the recent "nonblocking fix"
> applied, I'm totally innocent of this mess.
>
> As someone named John McCue discovered, the fcntl does actually affect
> the running operation, although in rather strange ways: In case a
> non-blocking read which happened to be blocking is interrupted (this
> shouldn't happen because it shouldn't block aka 'go to sleep in the
> kernel until some external event occurs'), the kernel tries to hide that
> by silently returning an EAGAIN error instead of an EINTR error. But it
> doesn't keep track of which calls were blocking and which
> weren't. The net effect is that a blocking call supposed to be restarted
> in case it was interrupted by a signal actually aborts with EAGAIN since
> glibc "doesn't expect that"

I was wrong about that: The behaviour is actually correct, although
somewhat counter-intuitive: The read is interrupted. It is then
restarted by the C library and fails with EAGAIN because O_NONBLOCK is
now set for the file descriptor in question. Minus the 'SIGCONT
interrupts' quirk, this is also the behavour in the other case.

Back to comp.os.linux.development.apps | Previous | NextPrevious in thread | Find similar


Thread

Linux O_NONBLOCK bug/ quirk Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-03-27 15:26 +0000
  Re: Linux O_NONBLOCK bug/ quirk crankypuss <crankypuss@nomail.invalid> - 2014-03-28 02:08 -0600
    Re: Linux O_NONBLOCK bug/ quirk Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-03-28 12:45 +0000
      Re: Linux O_NONBLOCK bug/ quirk crankypuss <crankypuss@nomail.invalid> - 2014-03-29 05:19 -0600
  Re: Linux O_NONBLOCK bug/ quirk Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-03-28 20:12 +0000
    Re: Linux O_NONBLOCK bug/ quirk unixb4coffee <unixb4coffee@gmail.com> - 2014-04-02 11:13 -0700
      Re: Linux O_NONBLOCK bug/ quirk Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-03 16:36 +0100
        Re: Linux O_NONBLOCK bug/ quirk unixb4coffee <unixb4coffee@gmail.com> - 2014-04-03 11:43 -0700
          Re: Linux O_NONBLOCK bug/ quirk Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-03 21:31 +0100
  Re: Linux O_NONBLOCK bug/ quirk Lusotec <nomail@nomail.not> - 2014-03-28 23:13 +0000
    Re: Linux O_NONBLOCK bug/ quirk Richard Kettlewell <rjk@greenend.org.uk> - 2014-03-29 11:15 +0000
    Re: Linux O_NONBLOCK bug/ quirk Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-03-30 19:42 +0100
    Re: Linux O_NONBLOCK bug/ quirk Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-16 12:42 +0100
      Re: Linux O_NONBLOCK bug/ quirk Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-16 13:36 +0100

csiph-web