Stas Bekman wrote:
if any of your programs rely on geppid, they will now be either broken or don't do what you want. I've discovered it while porting Apache::VMonitor, which shows you all the httpd procs and their system's usage, calculating the memory usage and shared memory usage. getppid gives me 1, which completely blows out my algorithm for calculating shared memory usage since it needs to know the memory used by the parent httpd process.
Why 1 ? because it's the ppid of the httpd parent process ?
No, it's because the httpd parent process is running as detached, so its parent is the init process (pid=1). The child process doesn't get its ppid updated, so it reports the grandparent pid.
>Besides it's a bug, no matter how you look at it, because a C call to getppid() from the same process will do the right thing.
That's in fact the whole point of the change : have perl's getppid() always return the parent process id, and not the parent thread id like Linux's getppid(2) when threads have been spawned.
Is this going to cause different classes of problems in prefork and threaded mpms ?
I don't know. Quite possible. I'll do the necessary testing tomorrow and report back if it's indeed a problem.
It had to be fixed locally in mp2 since 5.8.1 has been released already, meaning that anybody who uses 5.8.1 is vulnerable to this problem. Hopefully 5.8.2 will get it fixed in perl.
Hope so.
;)
Thanks Rafael ;)
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
