Well Tielman,
I think you are lucky that you don't have to catch the status of your
children!
Just one comment about: $SIG{CHLD} = 'IGNORE'; ## Children die unnoticed ...
I don't know exactly what your child does but if your child starts another
process again, you might run in trouble.
I coded a program which fired up Sendmail in the child (through Mime::Lite).
I had set $SIG{CHLD} = 'IGNORE'.
It took me 3 days to find out that Sendmail didn't return proper return
values anymore.
This was all due to the fact that MIME::Lite starts up a child process
itself and because of the IGNORE, it always returned the same return
value...
I know this is an aside but it might save you some headaches...
Jeroen
> Thanks Jeroen,
>
> Somewhere in my quest to solve this issue, I read to first
> unset the child signal with
>
> $SIG{CHLD} = 'IGNORE'; ## Children die unnoticed ...
>
> and then in the child use
>
> setsid or die $!;
>
> which supposedly immediately dissociates the child from the
> mother, which means the mother does not have to waitpid ...
>
> but, if i sleep a bit in both the mother and the child, and
> monitor this
> with watch, it's clear that the child does not immediately
> become a child
> of PID 1 (ie, it has dissociated/daemonised) on setsid -- that only
> happens when the mother has died ...
>
> With regards $dbh->{InactiveDestory}, I have tried it, but all
> without any success.
>
> In my specific case, the mother does not need to talk to the
> child -- the
> child must just fork, do it's thing and die.
>
> Conceptually, the following works well enough if placed in the mother:
>
> my $ppid = open (WRITEME, "| ./child-external-script.pl") or
> warn "Couldn't fork: $!\n";
> print WRITEME "MOTHER $$ CHILD $ppid";
> close WRITEME;
>
> But i'd prefer to have the child's code in a module, and the
> mother then
> just calling a function, ie
>
> ...
> $FORKING = 1;
> fork_to_child($$,"MESSAGE") if $FORKING;
> ...
>
> Children, children, children ...
> What can I say?
>
>
> Tielman
>
>
>
>
> On Tue, 07 Oct 2003 08:53:33 -0500, Jeroen Lodewijks wrote:
>
> > Hi Tielman,
> >
> > I had exactly the same problem (I asked about it about 2
> weeks ago). I use
> > Oracle though. Even if you don't use the handle from the
> mother in the
> > child, the handle still gets fucked up. The child will try
> to close your
> > handle.
> >
> > There is a modifier called InactiveDestroy, like:
> > $db->{InactiveDestroy} = 1;
> >
> > This supposedly will ensure that your handle isn't closed
> when the child
> > exist. It sure doesn't close the connection but it doesn't
> work for me.
> > The parent handle is just KAPUT. But this is Oracle, not
> Informix. It
> > might work for you.
> >
> > I have given up to it. I now close and open all database
> handles again and
> > again and again.
> >
> > PS I don't know how your forking is implemented but I sure
> hope that you
> > don't need to know any exit values from your children. I
> have noticed it's
> > *very* unreliable to depend on waitpid. Again, your milage
> may vary as
> > this Oracle. I know use pipes to communicate between processes.
> >
> > Jeroen
> >
> >
> >> Thanks John,
> >>
> >> But the idea here is that the child doesn't need a handle
> at all -- I
> >> just want the mother's handle to be "left alone" ...
> >>
> >> Tielman
> >>
> >>
> >> On Tue, 07 Oct 2003 09:09:58 -0400, John Saylor wrote:
> >>
> >> > hi
> >> >
> >> > no- fork YOU and die ...
> >> >
> >> > ( 03.10.07 12:31 +0100 ) tvilliers:
> >> >> I have a mother process which needs to fork off a child
> at every x
> >> >> milestone.
> >> >> Now, the mother has an open database handle, which from my
> >> understanding
> >> >> gets transferred to the child at fork. I want the handle
> >> to stay with the
> >> >> mother.
> >> >
> >> > why not have the child just create it's own handle? i'm no
> >> dba [but i
> >> > play one on the internet], but i've seen informix
> >> connection lists that
> >> > use PID for identifying the handles.
> >>
>
>
>
>
>
