Cathey, Jim wrote:
I think the key here is that the shell should do what it takes to make
things work correctly.
If by "things" you mean itself, then yes. If it can't tolerate
O_NONBLOCK being on, then it should be responsible for turning
it off.
Generally it probably ought to be off, since the general Unix
paradigm is that reads are blocking if data is not available.
Specific things that want to poll are expected to turn that
feature on, and given "Death from the Skies" of Unix the managing
shell should probably keep turning it off, since the offender
can't be expected to always clean up after itself.
-- Jim
I'm just worried about if I need to kill a process, or if one of my
processes has a bug that means it can't clean itself up. Seems like a
massive overhead leaving it not up to the shell IMHO, that I need to
execute a small program after any process that I don't trust, or that
might have crashed unexpectedly (that I might not be able to detect
immediately) to turn off non-blocking.
Personally, I'd really look forward to the shell ensuring that a known
environment is given to a process that is run.
I did some rummaging on the opengroup, and I found this:
http://opengroup.org/onlinepubs/7990989799/xcu/sh.html
"If the standard input to /sh/ is a FIFO or terminal device and is set
to non-blocking reads, then /sh/ will enable blocking reads on standard
input. This will remain in effect when the command completes. (This
concerns an instance of /sh/ that has been invoked, probably by a
C-language program, with standard input that has been opened using the
O_NONBLOCK flag; see /open()
<http://opengroup.org/onlinepubs/7990989799/xsh/open.html>/ in the *XSH*
specification. If the shell did not reset this flag, it would
immediately terminate because no input data would be available yet and
that would be considered the same as end-of-file.)"
Does this then imply that we really should be turning off O_NONBLOCK?
Cheers,
Jason.
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
