[MPlayer-dev-eng] Re: kernel: to do_select(pipe) or not to do

[Alexander Strasser]

D Richard Felker III wrote ( On Mon, Nov 22, 2004 at 10:45:43PM -0500 ):
> On Tue, Nov 23, 2004 at 01:23:30AM +0100, Gábor Lénárt wrote:
> > On Mon, Nov 22, 2004 at 05:02:04PM -0500, D Richard Felker III wrote:
> this is most certainly not one of them. i said that after select()
> returns writable, the _next_ write on the fd should not block. i

I really can't imagine how that should work, select knows nothing about
what you will write and a blocking pipe _will_ block _when_ the size is
greater than PIPE_BUF ( at least this was the idea, and I know of no
UNIX systems that do otherwise ). The select call only returns that the
fd is writeable and that is true, the fitting part of your write will be
written. But this does mean nothing about the write won't be blocked at
some time.
It simply doesn't know how much you will write and so it can't know if
your write will block or not or in other words if you will do a write
that is atomically possible or not. If you go for atomic writes they
shouldn't block if select() says the fd is writeable, so if this was
your concern select() behaves correctly and correctly breaks the mplayer
code that does stupid things.

Anyway this discussion renders pointless...

To go back to the original topic I think we should just remove the pipe
from the input system. Why?
 - it _never_ worked as expected... (shame on us we didn't see)
 - it seems/is plain stupid to have a blocking pipe as input buffer
   even if we try to use it in a non-blocking manner ( and this wasn't done right )
 - there is already (hopefully) more sane implementation for systems without
   select ( for example windows ) and by using this for all systems we could minimize
   the code a bit too.

  Alex (beastd)