Re: Question on select() and sockets

Alex Fraser <me@xxxxxxxxxxx> writes:
William Ahern wrote:
K-mart Cashier <cdalten@xxxxxxxxx> wrote:
[snip]
Perhaps I'm not thinking this through, but how

"This all sounds fine. But you must set the pipes non-blocking else
you
can still end up blocking, even if you only call read() or write()
after
select() says the descriptor is, respectively, readable or writeable:

Is this possible?
For pipes the scenario would probably involve another process or
thread
invalidating the condition.

I don't know of an implementation where read() can block after
select() says a pipe descriptor is readable, but as you described
there is at least one real-world implementation where this is not true
for sockets. I (amongst others) believe the implemented behaviour is
standards-compliant, but it seems that some people disagree with this
interpretation.

Some people apparently 'disagree' about the proper use of tenses in
written English (simplified) and they are (regretfully) past the point
where such 'disagreement' could still affect them negatively. But the
solution for this particular problem could be found in any grammar
book intended to be used in a 'medium-level' school.

Independently of this, this particular implementation happens to be
Linux and the consense among the people who wrote it (again
simplified) is that it does violate the standard, but that the
standardized behaviours isn't really useful in situations where a lot
of UDP-datagrams are expected to arrive and need to be processed in
realtime, eg any type of video- and/ or audio-streaming. With the
present implementation, the received datagram can be checksummed while
it is being copied into a userspace buffer, which cuts the necessary
memory accesses to do all of it by one third[*]. Which I consider to
be a valid argument.

[*] A VoIP-phone is not going to use a 'state of the art' PC
heating as CPU, if only because none would be willing to
accept the constants noise and the high power-consumption. For
a 200Mhz-ARM9-processor I happen to be somewhat familiar with,
eliminating redundant passes over the data to be processed
from the MD5- and AES-'scheduling code' in Kerberos 1.4.3
resulted in a throughput increase of more than 200 K/s.

.

Relevant Pages

  • Re: A Pipe To Die For#3
    ... Is it okay to believe that we can disagree with neither ... Does that mean that their pipes do not smoke as ... is not helpful to new pipe smokers any more than it is in science. ...
    (alt.smokers.pipes)
  • Re: Digital rights & LPs
    ... But I guess that best left for the "doobs vs pipes" debate. ... I often disagree with history. ...
    (rec.audio.pro)