[ ... 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/
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 21:00:17 EST