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