Folks, I got an e-mail from someone asking another question and decided
that I should also point out that the write() does eventually return a
non-zero value and data is written to the named-pipe. The data indicates
that the reader is busy and that there probably was a buffer full of data in
the pipe and that the write() would in a blocking mode would have been
blocked as you would expect. The code is 'working' with the exception
of the select() returning the fd when I don't expect it to and the write()
returning a 0 when I don't expect it to.
The whole point of this design was to allow the use of the non-block
write() on the named-pipe so that the process could continue to service
it's input stream and other functions that it performs. The expectations is
that the select() will block until interrupted by a signal, data from any of
the processes read fds arrives, or data can be written to the output fd for
the named-pipe. The problem is that select() is returning immediately
and the write() fails, we essentially are in a polling loop and this eats
the CPU to a much higher degree than desired -- in this application there
can be hundreds of these processes running on the same host.
Just wanted to make sure that I clarified everything that perhaps wasn't
stated in the original post.
> I've got a process that sets a named-pipe to be non-blocking. The first
> time that the process
> enters a situation where the write() would block it adds the fd into the
> select() calls set
> for writers. The expectation was that the select() would indicate that
> the fd was ready for
> writing and the write() would be accomplished. On an HP/UX box we have a
> where the process that is doing this logic starts to take a large
> portion of the CPU -- just
> as if it was polling the fd. I used the HP/UX tusc/truss command and it
> shows that what is
> happening is that the select() returns a 1 (with the indication that the
> fd that is being tested
> for writing is set), but the write() returns a 0 and nothing is written.
> I have always been
> under the impression that write() would return a non-zero value and that
> select() would not
> return the fd for writing if it wasn't really ready for writing.
> What is the problem with the logic in this case?
> Thanks for the help!