O_NONBLOCK on stdin left set by child (using ash shell)

Cathey, Jim jcathey at ciena.com
Tue Nov 10 23:34:28 UTC 2009


>But everything *is* working correctly. The program sets O_NONBLOCK
>on stdin and exits. Shell, being a stupid program, has no way
>of knowing whether this was intended or not, is better to leave it as
is.

Does shell also try to work with any/all odd settings
of the stty i_flags?  I thought it just whacked them to
what it needed and got on with life.

>Now (after 1.10.x) it is using nonblock_safe_read()
>instead of just safe_read(), and thus does not need
>to switch off O_NONBLOCK.

Clever, but was it a good idea?  That just exported
the problem to _every_ potential child process of a
shell.

>>alternative would be to fix nearly all apps that use stdin (cat, vi,
etc)!

Fix?  Mangle!  This is the wrong way to go.

>There are two ways: (a) detect and switch off O_NONBLOCK
>as shown above, or (b) use code which works correctly
>even on O_NONBLOCKed fd:

Not sure this (b) is a good idea.

>Or to bug kernel folks to finally do something about broken API.
>They might provide a way to do nonblocking reads without
>setting troublesome O_NONBLOCK bit. Then applications
>can slowly migrate to this non-buggy API.

At times like these I sure miss the nice async I/O of DNIX.
O_NONBLOCK had nothing to do with what reads did, it was
the old-school blocking open flag only.  AIO was conducted
via special read/write calls, the 'asynchritude' was tied
to the specific I/O request and nothing to do with the file
descriptor.  Made mixing and matching I/O styles seamless.
You could also use VMIN/VTIME to poll ttys, if you wanted to,
but that was strictly a non-native compatibility tool.
(Just as Berkeley sockets were on that platform.)  The
native servers used only AIO, programs were pretty simple
and bug-free as a result.  (Unless you couldn't grok
state machines, in which case your crap never worked
at all.)

-- Jim






More information about the busybox mailing list