in reply to Re^3: Fork parent process dies unexpectedly
in thread Fork parent process dies unexpectedly

Thanks to everybody that replied. This seems to be working as I want. I will read more about the EINTR signal. When the last child dies the error rasised by $socket->accept is "No child processes". I will look at Net::Server. It looks like what I need, but I am glad I took this approach to start. Again, my many thanks.

Ian

  • Comment on Re^4: Fork parent process dies unexpectedly

Replies are listed 'Best First'.
Re^5: Fork parent process dies unexpectedly
by thospel (Hermit) on Nov 19, 2005 at 22:46 UTC
    (again, everything in this reply is untested. Based purely on the problem description)

    Ah, that one is another result of the current perl handlers. The order of execution is now:

    - signal happens, triggers perl internals - flag for this signal is set by internals - systemcall is interrupted, $! set to EINTR - perl dispatcher sees flag, starts your signal code However, this code happens to change $! - The assign of undef to $conn happens - You check $conn, see its undef and then go look at $!, but you get the $! left by your signal handler, not the older one you really need.
    Solved easily enough by adding
    local $!;
    at the start of your signal handler.

    Personally I consider this a perl flaw/bug though. I think perl should localize $! when it calls the deferred user signal code.