Re: Sharing database handles across forked child processes

On Tue, Nov 13, 2007 at 01:18:25PM -0500, dan(at)sidhe(dot)org wrote:
> 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.

Yes, that happens.

> Am I at any risk in the parent process? That is, if the parent's got some
> transaction open, the child is forked, then the child either issues
> (perhaps in error) a command to the database or shuts the handle down, am
> I going to see any sort of corruption of the data on the back end?

Well,corruption of the backend is unlikely, but you're likely to get
and lot of strange errors on your other connections. That why I
suggested closing the filehandle behind the back of the library. Or
better, dup2() /dev/null over the top of it. Then during global
destruction it'll just think the DB went away.

It's a bit of a hack though.

> I fully realize this is a Bad Thing, no argument there -- I'm just trying
> to get a feel for my failure modes. If it's just going to be that the
> parent sees the handle go away that's one thing, if I'm going to see weird
> interleaving of commands from the parent and child or the back end's going
> to get confused enough to corrupt the database it's something else
> entirely.

I think the effect is comparable to two people typing into the same
shell, and each only getting half the output back. Sure, you're unlikely
to lose anything big, but do you want to risk it?

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Those who make peaceful revolution impossible will make violent revolution inevitable.
> -- John F Kennedy