Messages in this thread | | | Date | Tue, 10 Jun 2003 00:45:15 +0100 (BST) | From | James Stevenson <> | Subject | Re: select for UNIX sockets? |
| |
On 9 Jun 2003, Krzysztof Halasa wrote: > "David Schwartz" <davids@webmaster.com> 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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |