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

[D Richard Felker III]

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:
> > > 
> > > Maybe I'm wrong at this point but what about if you got "fd is
> > > writeable" from select but before reaching write() another
> > > thread got control and writes something?
> > 
> > this is not a problem unless you have more than one process/thread
> > writing the same fd at the same time, in which case you're either a
> > total idiot or you've already carefully thought out what should
> > happen. more likely the former if you're using threads to begin
> > with... :)
> 
> Sure, this is stupid example, but shows that doing select() and
> then doing write() using information got by select() is not
> a super stable solution at least.

it's totally stable if you're using only one process/thread or if
you're ensuring that only one thing is writing at once. naturally this
would be the case for network sockets and such.

> > > But this whole blocking/non-blocking issue from the point of
> > > view of the kernel is quite unknown for me, so maybe I'm wrong.
> > 
> > you're just asking about something entirely unrelated to the topic at
> > hand.
> 
> Not unrelated. Read again. It gives an example when you're
> not right (probably).

no it doesn't. there probably _are_ examples where i am wrong, but
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
didn't say anything about the next write by the same thread/process.
naturally if you're doing idiotic things where multiple threads are
writing the same fd at once it can't work.

rich