[PATCH] ash: clear NONBLOCK flag from stdin when in foreground

[Denys Vlasenko]

On Thursday 18 August 2011 00:31, Rich Felker wrote:
> On Thu, Aug 18, 2011 at 12:16:30AM +0200, Denys Vlasenko wrote:
> > On Wednesday 17 August 2011 23:20, Rich Felker wrote:
> > > I hate it when fools who don't know what they're doing and don't
> > > respect standards lobby for nonstandard behavior in Linux, thereby
> > > making the portability landscape *worse* than it already it. Instead
> > > try to understand why things are the way they are and just stop
> > > insisting on doing stupid things (like setting nonblocking mode on a
> > > fd you inherited).
> > 
> > I already asked this question and you ignored it.
> > So here it is again:
> > 
> > How can I do nonblocking read from fd 0 without
> > affecting other processes which might share it?
> 
> Assuming no other process will be reading at the same time,

No, I meant "how to do it the most general case". Including the case
when someone else reads concurrently.

> you simply 
> call poll first (or select, but select requires the fd # to be < 1024)
> to check that it won't block, then call read. select and poll are
> specified to only mark the fd readable if a read would not block.

An example from a different area of Unix API:

EINTR is supposed to be returned only if non-DFL,
non-IGN signal was reseived and handler was executed.
Right? Right... but...
real world chimes in: EINTR also may be returned if someone
happened to attach to your program with "strace -p PID"
while you are in a syscall. Syscall may return EINTR even though
*no signal whatsoever* was delivered.

Isn't it great when you try to debug a program with strace
and a hiccup like this makes it change behaviour
just because program author did not bother to check EINTR
"because it can't happen here"?

IOW: real world tends to be nasty. Defensive programming
is a good strategy. Using non-blocking I/O after poll/select
is one of those cases.


My question stands:

"How can I do nonblocking read from fd 0 without
affecting other processes which might share it?"

I don't need a lecture how I should use select/poll,
or that I shall not use nonblocking reads,
or that shared reads from shared fds are stupid.

I ask you how to perform nonblocking reads safely.
Because from where I sit, current Unix API doesn't provide
for 100% safe (wrt races) way to do it.

IOW: I want recv(fd, buf, len, MSG_DONTWAIT) equivalnet
which would work on any kind of fd, not only on socket fds.
Does it exist? Yes or no?
If no, why socket read op has this nice, non-racy nonblocking read
and ordinary read op doesn't? Isn't it a hole in API?


> If other processes might attempt a read at the same time your process
> does, then you have serious data races which are probably not solvable
> anyway.

Well, the data units might be single bytes.

> It's extremely rare that you would have a valid situation 
> where you need to do this; I sure can't think of any.

Again, answering something other than my question.
Not interested.

-- 
vda