Re: Detecting fork events in a module?

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.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Comment on Re: Detecting fork events in a module?

Replies are listed 'Best First'.
Re^2: Detecting fork events in a module? by cdarke (Prior) on Aug 02, 2007 at 13:49 UTC
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]
Re^3: Detecting fork events in a module? by BrowserUk (Patriarch) on Aug 02, 2007 at 14:00 UTC
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. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re^4: Detecting fork events in a module? by cdarke (Prior) on Aug 02, 2007 at 14:17 UTC
Fair enough. I almost suggested FD_CLOEXEC myself, but figured the guy wanted to stay within his module, since kingkongrevenge says: When a user of the module forks, I want to close the duped socket connection and open a new one. It is the opening of a new one that would be rather difficult after an exec - although not impossible if the exec was to perl with a -M option, and the module opened the new handle in its BEGIN block.	[reply]