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


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

>>     Nope, that's not what it says. It talks about operations that *WOULD*
>> not block, not operations that *WILL* not block. In other words, it tells
>> you what would have happened to the operation had it already been in
>> progress, not what will happen in the future.

> Non sense; there's no meaning in knowing what happened. And:
>
> """
> A descriptor shall be considered ready for writing when a call to an 
> output
> function with O_NONBLOCK clear would not block, whether or not the 
> function
> would transfer data successfully.
> """
>
> Cannot be possibly misunderstood. If you write it WILL NOT BLOCK.

    No, it does not say a *subsequent* operation *will* not block, it says a 
hypothetical concurrent operation *would not* block. These are *totally* 
different.

> Sorry, I forgot to mention, but I told it in the other mail, it WON'T
> NECESSARILY TRANSMIT ON THE NETWORK, what I meant is that the data is
> immediately transmitted to the network layer (That is, usually to some
> manager in the kernel), that will asynchronously deliver the data ASAP on
> the physical device. Anyhow, send() returns immediately after the system
> has accepted the data(*), and the process continues; it does not WAIT for
> an occasion to queue the data, that is the guarantee that is granted by
> POSIX standard.

    None of this changes the fact that on most POSIX systems, a 'write' to a 
TCP connection through a blocking socket will always block if the amount of 
data passed to 'write' is sufficiently large. No matter what 'select' tells 
you.

    Nothing in POSIX requires 'write' to return immediately on a blocking 
socket if it can't send all the data to the kernel buffer but can send some.

    DS

.