Re: PATCH Re: udp weirdness

[Eric Lemoine <Eric.Lemoine@ens-lyon.fr>]

> > >It is difficult task, if possible at all.
> > >
> > >The main obstacle is that we must not block after select() succeeded,
> > >otherwise applications will lockup. Taking into account nature of datagram
> > >services (and generally of networking services, where routes change et 
> > >al.)
> > >you do not know at time of select(), where the datagram will go.
> > >So, blocking can be made only based on a criterium not depending on this.
> > >problems with silent losses. People just do not care about this, so
> > >they get the thing which they deserve.
> >
> >Alexey,
> >
> >Would you mind explaining a bit more why apps will lockup if we block
> >after select() succeeded. Or anyone?
> 
> Actually, I'm more interested to know why we would **need** to block after
> select has succeeded.  It would seem to me that select is busted in this
> case.  For the case of a very large UDP packet and a small send buffer,
> select gets confused, but at least when the send buffer is > 128k, it should
> be right...

With the current impl. process calling sendto() doesn't go to sleep 
after select() has succeeded. My question applied in the context where 
process goes to sleep when the qdisc queue is overflowed.

-- 
Eric