Re: blocking read/write in socket

"Robert Harris" <robert.f.harris@xxxxxxxxxxxxxxxx> wrote in message
news:Vx79g.133048$tc.14612@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Alex Fraser wrote:
"Robert Harris" <robert.f.harris@xxxxxxxxxxxxxxxx> wrote in message
news:ml_8g.136610$xt.64419@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
[snip]
1. Don't call read() or write() from your server until you know, from
calling select(), that your read or write will not block.

If you have a blocking socket, and select() (or poll()) says it is
writeable, write() (or send()) may still block. I think this is obviously
true if you attempt to write more than one byte.

No (at least certainly not for TCP/IP). Your write() (or send()) may
write less than you requested and it will return the number of bytes
actually written.

In the absence of errors and signals, a blocking write() will write the
number of bytes requested, blocking the thread if necessary.

In fact, it is possible that write() will block even if you attempt to
write
just one byte (after select() indicates the socket is writeable).
Similarly,
it is possible that read() (or recv()) will block if called after
select()
indicates the socket is readable. The reason is perhaps not obvious but
quite simple: in general terms, the situation may change between the time
select() determines a descriptor is readable/writeable and a subsequent
read()/write() on that descriptor. The solution, of course, is to set
O_NONBLOCK.

If you do that, then a read or write that would otherwise block will
return with an error condition. If your process has nothing to do until
it can actually read or write (a common condition), then with O_NONBLOCK
set it will just waste CPU time looping whereas using select() or poll()
with blocking reads and writes will allow the process to wait until it
has something to do.

I did not mean to suggest setting O_NONBLOCK and looping instead of using
select() or poll(). My point was that using select() or poll() does not, and
cannot, guarantee that you will not block in a subsequent read() or write().
When you use select() or poll(), it is normally potentially disastrous (or
at least undesirable) to block in read() or write(). For the reasons given
above, you can only ensure that will not happen by setting O_NONBLOCK on the
descriptor(s).

In other words, "using select() or poll() with blocking reads and writes" is
generally a bug waiting to happen.

Alex


.

Relevant Pages

  • Re: pipe write buffer
    ... made WITHOUT blocking. ... every other function, 'stat', 'access'. ... The problem boils down to wether poll() selectdeliver "static" information or wether they deliver a snapshot from state at call-time ...
    (comp.unix.programmer)
  • Re: 8ms Timer for serial port access
    ... You can use 'poll' to tell when there's data ready ... >> 3) Repeat. ... >> 2) Read as many bytes as are ready without blocking. ... > Then I will have another delay before I can process the data. ...
    (comp.os.linux.development.apps)
  • Re: pthreads for serial programming
    ... > Can you make the file descriptor non blocking using ioctl? ... > you tried using poll with a timeout before the read? ...
    (comp.programming.threads)
  • [PATCH] sysfs: Make poll behaviour consistent
    ... was previously set to zero. ... also zero, so poll was blocking, regardless of whether the attribute ...
    (Linux-Kernel)
  • Re: recv blocks although socket is ready
    ... of the members of the interface in my network layer have blocking ... Only one has non-blocking semantics. ... call any socket operation and rely on the socket to block. ... Now I have to implement blocking myself in all other ...
    (microsoft.public.win32.programmer.networks)