kingkongrevenge has asked for the wisdom of the Perl Monks concerning the following question:

I'm writing a module that talks to a server. The module contains a socket connection to a server. When a user of the module forks, I want to close the duped socket connection and open a new one.

Is there an easy way to detect forks? Or to tell the OS not to dup a certain socket?

All I can think of is contrived hacks like monitoring $$ for changes in a separate thread.

Replies are listed 'Best First'.
Re: Detecting fork events in a module?
by Anno (Deacon) on Aug 02, 2007 at 09:43 UTC
    When a user of the module forks, I want to... . Is there an easy way to detect forks?

    No, there isn't. Your module could offer a forking method (or function) that registers the fork, for instance by storing the PID somewhere. Tell your users to use that instead of forking directly.

    Anno

[reply]
Re: Detecting fork events in a module?
by cdarke (Prior) on Aug 02, 2007 at 12:37 UTC
    In pthreads there is a thing called a "fork handler", see man pages for pthread_atfork.
    Basically it calls user written functions on a fork - "fork handlers" (and an opportunity for a Two Ronnies joke). Three handlers may be written, to be executed in the parent before the fork, in the parent after the fork, and the child after the fork (all are optional).
    The feature is meant for mutex handling, but I guess you could use it for this. The problem is that you would have to write it in XS.
[reply]
Re: Detecting fork events in a module?
by TOD (Friar) on Aug 02, 2007 at 05:54 UTC
    if you're on a linux box, then there's a $SIG{CHLD} to watch out for. see perldoc -f fork and perldoc perlipc
    --------------------------------
    masses are the opiate for religion.
[reply]
[d/l]
[select]
      The SIGCHLD signal exists on all Unix systems, not only Linux (and Perl probably emulates it on others), but it is issued when a child exits, not when it is created. The OP wants to "detect fork events" which appears to require the latter.

      Anno

[reply]
[d/l]
Re: Detecting fork events in a module?
by BrowserUk (Patriarch) on Aug 02, 2007 at 13:30 UTC

    I half remember something I scanned over when when writing Win32::Fmode that your question stirred in my memory. Since noone else has mentioned it, I will--though I can do no more than just mention it.

    Check out your man page for Fcntl() and FD_CLOEXEC. It might lend itself to your needs.

    File descriptors open in the calling process image remain open in the new process image, except for those whose close-on-exec flag FD_CLOEXEC is set; (see fcntl(2)).
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
Re: Detecting fork events in a module?
by BrowserUk (Patriarch) on Aug 02, 2007 at 13:31 UTC

    I half remember something I scanned over when writing Win32::Fmode, that your question stirred in my memory. Since noone else has mentioned it, I will--though I can do no more than just mention it.

    Check out your man page for Fcntl() and FD_CLOEXEC. It might lend itself to your needs.

    File descriptors open in the calling process image remain open in the new process image, except for those whose close-on-exec flag FD_CLOEXEC is set; (see fcntl(2)).
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
      FD_CLOEXEC will not help here, it closes the file descriptor on exec, not on fork. If an exec was issued the module (in memory) would be blown-away, along with any other code in the address space.
[reply]
        If an exec was issued the module (in memory) would be blown-away, ...

        Yes, in the child, only.

        But, the exec'd program would inherit the open file descriptor, which (I thought) might be why the OP want's to close it it. Hence the mench.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

Back to Seekers of Perl Wisdom