ssh client is setting O_NONBLOCK on a pipe shared with other processes

[Peter Stuge]

Doug Graham wrote:
> > So the make process gets an EAGAIN on the write syscall and doesn't
> > retry?  That sounds like a bug in whatever make you're using, since
> > that could potentially occur in other circumstances too.
> 
> What other circumstances?  EAGAIN means that something put the
> device into non-blocking mode, and normally, that should only happen
> if the program calling write had itself previously set O_NONBLOCK.

Any program which makes assumptions about fds that have been passed to
other programs risk that those assumptions no longer hold.


> I don't think programs that don't set O_NONBLOCK are required to handle
> EAGAIN or short counts.

Please think about that some more.

Case in point; EAGAIN can come if you give your fd to another process
and continue using it yourself.

Short counts; It is documented behavior that read() and write() may
return short counts. It is not documented why, so you can not make
any assumptions.

With Linux, the kernel code of the particular device driver determines
what read() and write() calls return, and because the userspace API is
documented to allow short counts the different drivers may and do have
different semantics for return counts, sometimes the way that fits the
particular device, sometimes such that the kernel driver is much
simpler, thus more reliable.

I ignored short counts because convenient, until it caused me a problem. ;)

Now I write a looping function called wr(), rd() do_write() or do_read().


> We are using GNU make 3.81 but newer versions of gmake do the same thing:

GNU programs are like other programs in that they aren't neccessarily
correct.


//Peter