Re^3: Fork-safe DBI handles via ChildHandles and InactiveDestroy

As far as the fact that a fork can sort of corrupt various resources which aren't even used in the subprocess... well, that's unfortunate, but not isolated to DBI connections.

Exactly. To be really careful, a program which forks should avoid letting the kids inherit such connections.

After Compline,
Zaxo

Comment on Re^3: Fork-safe DBI handles via ChildHandles and InactiveDestroy

Replies are listed 'Best First'.

Re^4: Fork-safe DBI handles via ChildHandles and InactiveDestroy
by etcshadow (Priest) on Jun 07, 2007 at 05:08 UTC

To be really careful, a program which forks should avoid letting the kids inherit such connections.

Ideally, that's exactly what I'd do. Unfortunately, I'm not aware that any such method really exists. If there is such a way, I'd love to learn about it. For anything that is some sort of file handle or socket (including all my examples above), the only way (that I know of) that you can "avoid letting the kids inherit" it is to close it before forking. Of course, that fails to meet the broader goal of isolating it from unintended side-effect. (Closing it is a pretty big side-effect.)

By the way, if this sounds argumentative, it's not intended. I'm aiming for "inquisitive". (It can be very hard to accurately convey tone in a text-only medium.) I'd really like to learn more about what facilities there are for making this kind of mess easier (if any exist). I can't tell if what you're saying is "Too bad this sort of necessary when dealing with sockets and handles and forks" or if what you're saying is "Geez, I can't believe you don't know about MagicallyAwesomeFork that allows you to selectively not copy portions of your process in the fork." Although I'm confused as to how that could possibly be accomplished, I'd definitely like to learn.

------------
:Wq
Not an editor command: Wq
[download]

[reply]
[d/l]


more useful options
	PerlMonks