If the socket is set not to block, then the socket will read as much
data as is available and the underlying read call will return the
number of bytes read, right? So the poll will still be useful in an
On 10 Oct 2008, at 12:36 PM, Alexander Burger wrote:
> Hi Tomas,
>> The comment is a bit misleading as it does not prevent blocking
>> really. The data might be available but the 'read' function might
>> still block.
> Yes, all those comments regarding non-blocking (also in the way Konrad
> used it) mean that during normal operations (i.e. not hanging in an
> error condition) everything will go smoothly. It does not mean
> "non-blocking" in the technical sense. But for those "normal"
> operations, it goes surprisingly well when messages observe the
> limit. So the *application* is non-blocking, not the underlying
> protocol. Without *Run and (poll) the input would always block even
> on a
> single input channel.
> - Alex
> UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]