Messages in this thread |  | | From | Terry Lambert <> | Subject | Re: kqueue microbenchmark results | Date | Thu, 26 Oct 2000 06:10:52 +0000 (GMT) |
| |
[ ... blocking read after signalling that data is available ... ]
> Yes, and as you mentioned, it was _bugs_ in the operating system > that did this.
I think it's reasonable for the OS to discard, for example, connection requests which are not serviced in a reasonable time window. Likewise, it's reasonable to consider some protocol that would allow the sender to repudiate a packet that it decided that it didn't want to send; this would, in fact, be extremely useful in multicast protocols that signalled all available servers with a request, and then repudiated the request after receiving a response, on the theory that the server was too loaded, or the link to congested, or the programmer of the repudiated servers was such a bad coder that the server was too lazy to get off its butt and answer the request in a reasonable amount of time.
A protocol based on this second approach would actually be able to solve "the gnutella congestion problem" (quoted, as I believe it's simply a case of the universe and the laws of physics voting against gnutella as being a dumb idea, since it's just a repeat of the original NetWare and LANMan scaling problems).
The real problem is that the interface is making a potentially incorrect assumption about the underlying implementation, and that means that it won't be portable to systems whose underlying implementations don't satify the (undocumented and unwarranted) assumption.
People whine about WSOCK32 being "gratuitously different" with regard to resource tracking and implying a shutdown on a socket close or an application exit, but they forget that that all came about because the original interface, and the programmers who used it, assumed a kernel space implementation, and that the kernel would resource track sockets, as if they were file descriptors.
I think your Sun example:
> POLLIN Data other than high priority data may be read > without blocking. For STREAMS, this flag is set in > revents even if the message is of zero length.
Implies that a recv or recvfrom is required, and use of a read after a POLLIN, which can't retrieve high priority data from a socket, may result in the process blocking. Well, "duh!", the read is on the normal data channel, and the POLLIN corresponds to the high priority channel ...what did you expect, when you called the wrong system call on a socket?
> I see a trend here, let's try Linux:
Linux also thought it was OK to modify the contents of the timeval structure before returning it.
Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |