Re: In which case write() will be blocked


Binary wrote:
Hi DS,

Do you know which reason will cause this problem?
How can I know
whether the peer is not fast enough to read the buffer and is there a
place to check the buffer status?

The problem is in a server daemon, which has many client, if the
problem occur, the only info is the fd number.

ABAI

The problem is almost certainly that the server absolutely cannot
afford to block, but does not tell the kernel this by setting the
socket non-blocking. If you absolutely, positively cannot block, you
must never ever make a call that can be blocked indefinitely. A 'write'
or 'read' to a connection over the network can block indefinitely.
(Even if you 'select' first.)

DS

.

Relevant Pages

  • Re: In which case write() will be blocked
    ... Do you know which reason will cause this problem? ... whether the peer is not fast enough to read the buffer and is there a ... place to check the buffer status? ... single UDP datagram.) ...
    (comp.os.linux.development.apps)
  • Re: O_DIRECT question
    ... the disk isn't a good idea IMHO. ... There is a reason that read and write return the ... fsync between both sets of writes, but that will flush any other ... The large buffer size really has little to do with it, ...
    (Linux-Kernel)
  • Re: [Newbie Question] Magic Numbers dangerous?
    ... > reason can be documented with a well-chosen variable name. ... it's generally a matter of taking a guess. ... where memory is typically allocated in pages of a power of two in size. ... ideal buffer sizes, then most of us haven't yet been informed. ...
    (comp.lang.java.programmer)
  • Re: sharing memory with non-children
    ... > program that uses shared memory and semaphores to make a pseudo-pipe ... If you STREAM the data from one process to the another, ... necessarily need a big buffer. ... > is no good reason to do so. ...
    (comp.unix.programmer)
  • Re: [Newbie Question] Magic Numbers dangerous?
    ... >> reason can be documented with a well-chosen variable name. ... > buffer sizes, it's generally a matter of taking a guess. ... > the guess is a power of two, because it works better with MMU/paging ...
    (comp.lang.java.programmer)