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, 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.

There used to be bugs in Linux UDP where select/poll could mark a
socket readable when a packet arrived, then read would find an invalid
checksum and block. This bug affected MaraDNS and was reported and
treated as WONTFIX at the time, but it was silently fixed some years
later. As far as I know, no such bugs exist anymore; if they do, they
are genuine bugs that contradict the explicit requirements of POSIX.

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. It's extremely rare that you would have a valid situation
where you need to do this; I sure can't think of any. The only
portable solution here is to use POSIX AIO or a dedicated reader
thread. (Note that the reader thread approach, along with pipes, can
be used to get poll-like behavior for ordinary files for realtime
applications where having read stall waiting for disk io would not be
acceptable.)

Rich
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox

Reply via email to