Stas Bekman wrote: > > > > 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>. > > Yes, but we aren't talking threads here. This behavior is true under > mp2/prefork mpm where we have no threads, but processes. We run in the > threads-friendly environment, so you can spawn threads if you want to (e.g. if > you want to use more than one perl interpreter under the same process).
I was providing some background on the rationale behind this change. Basically the consensus at the time was that $$, getp?pid and POSIX::getp?pid need to be portable, i.e. return the same process id from different threads ; and consequently that Linux's non-standard behavior of assigning differents PIDs to different threads had to be hidden. > I think the really proper algorithm is to leave the current behavior > only if perl was the one who did the fork (which will probably require yet > another PL_ flag. And if that flag is not set the pp_getppid logic should be > changed to cache that value and raise that flag. Something like this: Yes. I'll take a look at this this week-end if nobody beats me to it. > First of all, do you think this change (if left unmodified) is suitable for a > maintenance release? Well, the pid change is already out there in perl 5.8.1, so we need to make it more friendly for applications that embed perl on Linux. I think the fix should go both in blead and maint. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
