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

[D Richard Felker III]

On Tue, Nov 23, 2004 at 10:30:26AM +0100, Alexander Strasser wrote:
> 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.

afaik it does mean this for network sockets, but apparently pipes have
some very strange behavior to assure that small writes are atomic and
such. anyway what i said is still true if all writes are 1 byte. :))

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

agree!

rich