Re: select for UNIX sockets?

[James Stevenson]

On 9 Jun 2003, Krzysztof Halasa wrote:
> "David Schwartz" <[e-mail]> writes:
> 
> > 	It really doesn't matter. UDP applications have to control the transmit
> > pacing at application level. There is absolutely no way for the kernel to
> > know whether the path to the recipient is congested or not.
> 
> Because what? The kernel knows everything it has to know - i.e. complete
> state of socket queue in question.

yes it does when you call select

take a probgram thats sharing the same cosket between 2 processes
or a multithreaded program sharing any socket from the time
that select is called and read / write is called the data
or buffer form the socket could have been completly filled or completly 
emptyed.
 
> But if select() on sockets is illegal, should we make it return -Esth
> instead of success. Certainly, we should get rid of invalid kernel code,
> right?

nobody said it was illegla but in certin situations it
might as well count as a nop;
 
> > 	The kernel can't tell you when to send because that depends upon
> > factors
> > that are remote.
> 
> Such as?

if you are on a udp socket say you have host a host b and host c
host a and host b are on the same network host c is on another networked
connected by 512kbit link (faster / slower) and you are calling select on
host a. host b blast a silly amount of data to host c
host a does the same. What happen ? who wins ?

> > 	Yes, it would be nice of the kernel helped more. But the application
> > has to
> > deal with remote packet loss as well.
> 
> Could you please show me a place in the kernel which could cause such
> a loss on local datagram sockets?
> 

Same as a multithreaded program select could say its ok to write when you
write data it could be a completly different story