in reply to IO::Socket::UNIX unexpected death

It looks like you are trying to use the reader as a server since it's the one calling 'accept'. The process that continues running should have that role.

Otherwise, the socket object ($write) loses its counterpart when the reader exits, and would have to reconnect.

Suggest: move your accept call to the server side. Servers usually check for new connections and 'accept' them, or dedicate a thread to blocking accept calls and using worker threads to handle the connections. Unix socket files may be slightly different (I haven't used them much), but I expect the principles to be the same.

Replies are listed 'Best First'.
Re^2: IO::Socket::UNIX unexpected death
by lom (Sexton) on Jun 30, 2009 at 11:57 UTC

    Hi, thanks for your suggestion.

    The accept call will indeed be server-side. Actually, there will be 2 services speaking to each other through 2 sockets. This case (reader being restarted) is an exceptional case, but it happened during my tests and I wanted to be sure to handle that properly before going live.

    the socket object ($write) loses its counterpart when the reader exits, and would have to reconnect.
    It makes perfect sense, but I am surprised there is no other way than trapping SIGPIPE to catch this.