Re: designing around it: true. Unfortunately, this code was originally for perl 5.5 (we only recently upgraded to 5.8), which didn't support weak referrences. Holding some sort of internal list of all the connected dbhs
without weak referrences would have meant (indirectly) subverting the implicit disconnect when dbhs fall out of scope (which is generally a good thing). That would have been a bad thing.
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. A similar thing happens with IO buffers, necessitating that you do something like "flush all handles" before a fork. Unfortunately, this, too (at least used to be... someone may have fixed this since I last looked into it) has no good solution, as it requires the forking code to somehow reach out and grab a list of all of a process's resources of a type (in this case database handles, in that case buffered IO handles). Similarly, in apache, there's a necessary step of calling "cleanup_for_exec", so that child processes' sockets don't get selected for handling new requests. The list goes on, I'm sure... which is sad, because it means there's a whole laundry list of things you need to remember to do if you want to fork... forgetting to do any of them meaning a potential obscure bug.
------------
:Wq
Not an editor command: Wq