Just to sum up the discussion as it was extremely helpful and educational:
> > Hm... I get it and I don't get it... Who keeps the sub _dummy - the parent
> > or the child? I need to use DBI in it so I guess InactiveDestroy must be set
> > to true there. How do I find out who is who not at the time but after the
> > fork? Is this portable to win32? (the final version must run on win32 as
> > well).
> > Actually from the little I know about forks I thought that both parent and
> > child get copies of the very same stuff. So both get a "hot" DBI and
> > DBD::Mysql tied to the same socket... if this is at all possible. On the
> > other hand I am not using DBI anymore while in the reader (child?), just the
> > parser, so it shouldn't matter... Wow I am even more confused now :)
> >
>
> Ah, fun with IPC :-). The sub _dummy is the parent, because that is what
> you are controlling, technically you aren't even supposed to be aware
> that there is a fork (and weren't, really, until I told you :-)). Yes
> you are correct, everything is shared across the fork, the $dbh being
> one of those things. Normally if you were controlling the fork/exec
> model then you could decide to set InactiveDestroy in whichever place it
> was needed, it would actually be the child as that is what is exiting
> early (it does the retrieval). But in this case since the fork/exec is
> encapsulated in a module you didn't write, you will likely want to set
> it at connection time so that it is set on both of the handles. The key
> in this case is that you have to do your explicit commit/disconnect
> (which you were already). Theoretically another option would be to set
> it during construction, then unset it in the parent after the fork,
> assuming this works as I am thinking (caveat), then that might be better
> as it should make sure to do the normal DBI cleanup. Of course back to
> my caveat, since you don't really have control of when the fork is going
> to exit this might be trickier. Though *I think* (no guarantee) that the
> parser is reading from the pipe created for the fork, so as long as the
> parser isn't finished the pipe and child should be active. Sorry if I am
> confusing you again, the route I would take would be to set it during
> construction because that is the simplest, then test, test, and test
> some more. Try it different ways and see which works the best in the
> tests. See if you can get it to break again.
I didn't like the second variant, mainly because this really throws the
whole cleanup mechanism of DBI in the bucket. Suppose I made a typo that
will cause the whole thing to die at runtime. Depending on the database
engine I could get an undesired commit of the last transaction if the socket
just closes. The natural thing to do for me was to preceed the call
of the forking function (namely parseurl) with
++$dbh->{InactiveDestroy}
and then add
undef $dbh->{InactiveDestroy}
as the first line of &_dummy(). Worked like a charm since then.
> Whether or not this works correctly on Windows I have no idea, and
> wouldn't even venture to guess. You may want to read up on IPC on
> windows and fork/exec for that platform.
Looks like everything works fine, however I did only several test runs,
leaving the main drill for when I will be testing the entire thing under
Win32.
On an unrelated note - is there a generic way to trap this kind of things?
Or way to do partial forks (e.g. disable socket sharing)? Probably those
situations do not happen very often, but if I use a module that is not um...
ForkSafe like DBI (in other words it does not offer a way to skip the
destructor), and if I use some fat module from CPAN that relies on another
group of modules just as fat and so on and so forth, and I end up with a
fork() encapsulated several levels under the main::use pragmas - starts
sounding like a nightmare.
> etc. Watch out for the slippery slope with this argument, I mean, you
> could just write it all without modules, you could write it all in C,
> you could write it in assembly! Boy what fun that would be.....
I just made up my mind about my after-retirement plans! :)
Thanks!
Peter
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
