Which pid? The child may very well have forked and exited so the parent is
actually talking to its grand-children, it could also be that multiple
processes are sharing the same socketpair on the other side (that's another
contingency I'll have to take care of).
Then again - if the socketpair() is "connected" (e.g. SOCK_STREAM or
SOCK_SEQPACKET) then the kernel will notify the parent as soon as the other
side was closed. Remember we are talking about Unix domain sockets.
See:
http://www.erlenstar.demon.co.uk/unix/faq_2.html
1.1) last 2 paragraphs and 1.6), 1.7) . Note the part about 'not
confusing inetd' at the end of 1.7). This is almost the problem you
have.
Any sockets which are not TCP sockets do not have a 'remote' close
mechanism. This includes all UDP an unix domain sockets as well as fifos
and other devices like that. All of these need to be taken care of by
their respective applications. There is NO mechanism in the system to
check or guarantee anything about them. They are entirely owned and
operated by the process(es) that own them. If the remote goes away and
these resources are accessed in blocking mode without a timeout then the
accessing process will hang forever. This is normal. It is up to the
programmer to prevent this.
Peter
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
