read() problem

read() problem

Post by Zork Melin » Fri, 05 Mar 1999 04:00:00



[|)not able to read 0 for the client process running on the prompt and thinks
[|)that the client is still alive whereas we have actually killed it. What is
[|)the problem..? Why the server is not able to find that the client has died..?

Are you openning sockets before doing a fork? A child inherits all open
file descriptors, and the socket remains open as long as one process still
has a file descriptor for it.

Or maybe not.

--
Fe mhats enearha esma; iufue dolha soentrides odoem esri.
Fe bhuearai osraha esma; iufue auaen bhuearai shahem essa.

http://www.geocities.com/SoHo/Studios/5079/index.html
No Amigas were harmed in the writing of this missive.

 
 
 

read() problem

Post by Phil Howa » Fri, 05 Mar 1999 04:00:00



| Hi, I have a client process that creates one more client process in the
| background communicating with a server. I forcibly kill the client process,

Which client process do you kill?

| then the server is able to know that the client process running at the
| background has exited when the read() of the server returns 0 ... but it is
| not able to read 0 for the client process running on the prompt and thinks
| that the client is still alive whereas we have actually killed it. What is
| the problem..? Why the server is not able to find that the client has died..?
| Please reply.

I guess it would be more twisted to be killing the parent, so I will assume
you are killing the child.  The parent and child are sharing the same socket
that is connected to the server unless the parent closes it's copy.  If the
parent does not close() the fd for the socket sometime between when the
fork() succeeds and when the child dies or exits, the socket will remain
connected and the server won't know anything really happened.  Unless for
some reason the parent also needs to continue talking to the server along
with the child (can be very confusing) the best place to close the socket
in the parent is immediately after the fork.  And alternative that may be
an option for you is to fork the child before connecting to the server, and
let the child do the work.  If you're doing blocking I/O (if you don't know
what that means, then yes you are), having the child do the connection will
let the parent continue to interact with the user at the tty prompt even
while the connection is being attempted.

--
 --    *-----------------------------*      Phil Howard KA9WGN       *    --
  --   | Inturnet, Inc.              | Director of Internet Services |   --
   --  | Business Internet Solutions |       eng at intur.net        |  --
    -- *-----------------------------*      phil at intur.net        * --