Stas Bekman wrote:
> It looks like 5.8.1 started to cache ppids in PL_ppid, which wasn't the case
> in 5.8.0. When ithreads are enabled the new logic updates PL_ppid in pp_fork,
> which now does:
>
> PP(pp_fork)
> {
> ...
> #ifdef THREADS_HAVE_PIDS
> PL_ppid = (IV)getppid();
> #endif
THREADS_HAVE_PIDS is only defined on Linux.
The relevant section of the docs is in perlvar/$$ :
Note for Linux users: on Linux, the C functions C<getpid()> and
C<getppid()> return different values from different threads. In order to
be portable, this behavior is not reflected by C<$$>, whose value remains
consistent across threads. If you want to call the underlying C<getpid()>,
you may use the CPAN module C<Linux::Pid>.
> So if an application running embedded perl wasn't forked by perl's pp_fork,
> it'll have this problem. Under mod_perl 2, we get getppid reporting 1 from the
> forked process, when pstree clearly shows that this is not the case.
Yes. I didn't thought about this problem.
> I have a workaround for mp2:
>
> #if PERL_REVISION == 5 && PERL_VERSION == 8 && PERL_SUBVERSION == 1
> {
> #ifdef THREADS_HAVE_PIDS
> #ifdef USE_ITHREADS
> MP_dSCFG(s);
> dTHXa(scfg->mip->parent->perl);
> PL_ppid = (IV)getppid();
> #endif
> #endif
> }
> #endif
>
> which can be run at the child_init phase, immediately after a new process is
> forked. But may be it's something that need to be fixed in perl, as it worked
> just fine with 5.8.0, and is probably an inappropriate change in behavior for
> a maintenance release? If not please let me know, so that I'll change the
> workaround's ifdef to match 5.8.1+.
Currently PL_ppid is initialized in S_init_postdump_symbols.
I imagine we could initialize or reinitialize it later at a time
more suitable if there is some routine to be called back at fork
time.
Perhaps should I add a note in perlembed.pod about this problem ?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
