Subj : Re: Threading and Timeouts
To   : comp.programming.threads
From : David Schwartz
Date : Wed Jul 20 2005 10:29 pm


"Giancarlo Niccolai" <searchforme@ingoogle.com> wrote in message 
news:dbmr19$3bb$1@newsread.albacom.net...

> If you see a ready-for-read condition from one socket, it can be only
> ready-for-read again when you read it. It may be pushed anything from the
> other side, or it can be closed, or the interface may be set on fire on 
> the
> meanwhile, yet, in the real world, unless you make deliberate actions to
> destroy its readability from somewhere else, the data sitting there for 
> you
> to be read will still be there for you to be read after a while. [I agree,
> this is not in the standard, and I agree, it is not mathematically 
> correct,
> but read on].

    So you are saying it's impossible to create a network protocol that 
allows one side to 'revoke' data before the other side reads it? Or you are 
saying that for such a protocol, 'select' must be considered to have read 
the data?

> Same for writing. A socket that is ready for writing and that WON'T be 
> used
> by any other process in your machine, will be ready for writing also at a
> later moment, even if the interface explodes (unless the explosion 
> destroys
> also the CPU, but this brings in other problems that are not defined in 
> the
> standard, as i.e. how much of the latest instruction the CPU(s) is/are
> processing is really completed?). If the interface explodes, provided the
> kernel is still running, it will still accepts, without blocking, what a
> write() provides.

    So are you saying that a kernel can't block a UDP socket if it has 
momentarily lost the route it wants to send the data on?

> I won't claim anymore this is in the standards; I just misread them. But I
> still confident in claiming that without erroneous programming of the
> system applications, the positive check resulting from a select is not
> going to change, and is still available for the application to use at 
> *any*
> later moment.

    That's just not true. There are any number of interesting cases where 
the readiness changes for very strange reasons. A good example is 'select' 
on a listening socket where the connection resets or disappears before you 
manage to call 'accept'. This is not an error on the listening socket, so an 
error return from 'accept' is not required and there is no connected socket 
to return an error for.

> BUT, while it is not correct to *base* an application on this assumption, 
> it
> is correct to *exploit* it, provided a different outcome (i.e. read() on a
> ready-to-read socket actually blocking) won't cause the application to
> mis-function; as any error condition must not cause a correct program to
> fail, then THIS error condition (blocking on a socket after select() has
> said it's ready) must be correctly dealt too, or the consequences of not
> dealing with it must be accurately known.
>
> Am I correct up to this point?

    So long as you understand that the function might block, then fine. My 
point is simply that the operation might block. If you don't mind, then go 
right ahead.

    DS

.