Subj : Re: Threading and Timeouts
To   : comp.programming.threads
From : Giancarlo Niccolai
Date : Wed Jul 20 2005 11:26 pm

David Schwartz wrote:

> 
> "Giancarlo Niccolai" <searchforme@ingoogle.com> wrote in message
> news:dbld49$blc$1@newsread.albacom.net...
> 
>> After a call of select() which determines that the socket is READY for
>> I/O,
>> you are guaranteed to be able to send SOMETHING on the socket. If it's
>> UDP,
>> that means that there is enough space to send a datagram, if it's TCP
>> that at least one byte can be sent without blocking.
> 
>     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.

>> Actually, a write() on a socket will return the number of bytes actually
>> transmitted, and NOT THE ONES YOU WISH TO TRANSMIT. So, your assertion
>> "The
>> simplest example is if you 'write' more bytes than there's buffer space
>> for. A blocking socket will block until all bytes can be queued." is
>> wrong,
>> because if select determines that the socket is ready for write, the
>> blocking socket WON'T BLOCK and will TRANSMIT IMMEDIATELY the portion of
>> the data you requested to send that can be transmitted immediately.
> 
>     Huh?! Yes, it will block. It will block until all the bytes can be put
> in the buffer. It will send immediately and then block.
> 

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.

(*) The way the data is accepted by the system may be system dependant;
Theoretically it may also block the whole kernel, at least on a processor,
for immediate physical delivery. So there's no guarantee in POSIX that
send() won't actually last a very long time, but it is guaranteed that the
time spent in send() won't depend upon getting "the resource ready". When
select says "ok, it's ready for write", then IT IS IMMEDIATELY READY FOR
WRITE, and you'll deliver the data to the underlying protocol IMMEDIATELY.

Bests,
Giancarlo.

.