>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
>
>> Yep, this is a fork without exec. And the child processes often aren't
>> even doing any database access -- the database connection's opened and
>> held, then a child is forked off, and the child 'helpfully' closes the
>> handle during the child's global destruction phase.
>>
>> Am I at any risk in the parent process?
>
> Yes. But there is an easy solution, asuming you are using DBI:
>
> $dbh->{InactiveDestroy} = 1;
>
> This tells DBI not to do anything special when inside of DESTROY. Set
> on the kids immediately after forking.
I don't currently have a wedge into the parts of the programs that're
forking. I'd hoped to avoid having to, but at this point I'm thinking that
was a touch naive. (I'm also thinking I may want to hassle Rafael into
putting a post-fork handler into 5.10, but that's a separate issue)
>> "the child processes often aren't even doing any database access"
> ^^^^^^^^^^^^
>
> Often aren't? This should be "never", period, unless the parent contracts
> to stop doing database access after the fork. You can't have two processes
> sharing a handle.
The child processes are supposed to get their own handles; there's some
caching involved, but the cache checks pids. That doesn't mean the
children all do get their own handles, just that they're supposed to.
Regardless, at this point I'm sufficiently convinced that things will
potentially be bad (or at least annoying) enough that it warrants fixing
it now, rather than just putting it off and relying on error traps.
-Dan