Very Computer

What is the problem with the logic in this case?

Thanks for the help!

Roger

Read p154,"Unix Network Programming"-Vol 1, W.Richard Stevens

When write return 0 , it means the kernel buffers for the socket are full.

Use setsockopt() to change these socket options.

--

Nithyanand.
Siemens, Bangalore, India.
(Opinions expressed are my own and do not reflect the opinions of my
employer, Siemens)

Quote:> even when
> Read p154,"Unix Network Programming"-Vol 1, W.Richard Stevens
> When write return 0 , it means the kernel buffers for the socket are
> full.Use setsockopt() to change these socket options.

 Roger> but the write() returns a 0 and nothing is written.

are you sure? (write should not return 0)

make sure you used O_NONBLOCK and not O_NDELAY to set nonblocking
mode. Note also that select will return that the pipe is writable if
_anything_ can be written to it; it doesn't mean that an arbitrarily
large write will succeed.

--
Andrew.

comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>
                           or <URL: http://www.whitefang.com/unix/>

--

Nithyanand.
Siemens, Bangalore, India.
(Opinions expressed are my own and do not reflect the opinions of my employer,
Siemens)

that the fd I'm interested in is the one that caused the return. The output
from
truss on the write() is what I don't really understand -- I have basically said

that if I can't get an answer from here that I will have to conclude that there

is either a problem in the implementation of write() in the HP library or the
tusc/truss command isn't capable of tracing the execution correctly.

We only use O_NONBLOCK for this code and if the write() returned some
non-zero positive value the process would deal with that correctly it appears
from review of the code. We determine the size of the write() based upon
the number of bytes to be written or the OS's supported maximum size for a
named-pipe (in this case it appears to be 4096) whichever is less. I would
understand if the write() was sending a partial set of data out and returned a
number smaller than the requested size, but am perplexed by what tusc/truss
is showing me.

Thanks for the comments!

-Roger

Quote:>Well I can't think of any time write() would return the 0 and so that is why I
>decided to ask here. I use truss all of the time on SUN boxes and trust it to
>give me the complete and correct execution, but I've never used tusc/truss on
>the HP box before and don't know if I should trust it or not. The output from
>the truss is clearly indicating that select() is returning with a 1 and showing

>that the fd I'm interested in is the one that caused the return. The output
>from
>truss on the write() is what I don't really understand -- I have basically said

>that if I can't get an answer from here that I will have to conclude that there

>is either a problem in the implementation of write() in the HP library or the
>tusc/truss command isn't capable of tracing the execution correctly.

But if you want to be sure, why don't you modify your program so that it
displays what it's doing when it calls select() and write(), instead of
using truss?

--

Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

Yes we are going to do that, the delay in doing so has been due to the fact that
we can only duplicate this on our customers installation and so it's a little more
difficult to deal with. I've never used DDE (not an HP kinda guy I guess and we
don't have lots of customers on that platform), but we have also requested that
it be install so we can trace the execution in the de* -- so much simpler
in the SUN world it seems to me.

I can believe that the select() is having the problem and shouldn't be returning
with the fd set, but do that explain the write() returning a 0? I would expect to
see a -1 and an errno value telling me that the write() would block or couldn't
be completed for some other reason. I don't know when write() can actually
return a 0, not that I'm an expert on that issue which is why I decide to seek any
insights from this forum.

Thanks for the comments!

-Roger

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.

Regards,

Roger Hosier

| 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
| positive
| 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

There is one condition when write() can return 0 validly.  That is when the
length given to it is 0.  But I'm assuming you would have seen a 0 length
on the write() call in the truss output.  I'm inclined to assume an
implementation error.  It wouldn't be the first I've heard of for that
system.

--
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |

-----------------------------------------------------------------

Yes the tusc/truss output shows that the write() is attempting to put out 4K of
data and it gets the return value of 0. We have been able to duplicate the issue
with the write() returning a 0 on a SUN platform, but the select0 works as we
expect it to on the SUN and doesn't return that the fd is writeable until it is in
fact reading for writing. At this point we believe that the problem is in the way
that HP has implemented the select() functionality -- I should note that it does
not seem to resolve to a poll() call the way that the SUN implementation does
and so we are considering running a test to see if the poll() function for the
HP works as expected or not (I assume that HP has poll() but haven't really
checked on that yet).

Thanks for the help!

-Roger

| Yes the tusc/truss output shows that the write() is attempting to put out 4K of
| data and it gets the return value of 0. We have been able to duplicate the issue
| with the write() returning a 0 on a SUN platform, but the select0 works as we
| expect it to on the SUN and doesn't return that the fd is writeable until it is in
| fact reading for writing. At this point we believe that the problem is in the way
| that HP has implemented the select() functionality -- I should note that it does
| not seem to resolve to a poll() call the way that the SUN implementation does
| and so we are considering running a test to see if the poll() function for the
| HP works as expected or not (I assume that HP has poll() but haven't really
| checked on that yet).

I would assume (but that is often dangerous) that HP/UX has poll() since
that's a SysV thing.  Let us know if poll() works properly there.  I have
pretty much switched to using poll() for all the code I write that needs
non-blocking I/O.

--
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |

-----------------------------------------------------------------

Sorry for the delay in the response, been busy!!

We never did the switch to poll() to test this since we had some issues with the
HP/UX patch levels that we were pursuing. We've got HP involved in this as of
today and so we'll know more soon I hope and I'll post the results. Why have you
gone to poll(), is it just a portability issue or some technical issue you had?

Thanks!

Roger Hosier

| We never did the switch to poll() to test this since we had some issues with the
| HP/UX patch levels that we were pursuing. We've got HP involved in this as of
| today and so we'll know more soon I hope and I'll post the results. Why have you
| gone to poll(), is it just a portability issue or some technical issue you had?

Since I mostly use Linux, and Linux is going to poll() as the principle
syscall, I decided to try it out.  I found it to be easier to interface
with than select().

--
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |

-----------------------------------------------------------------