On Wed, 30 Jul 2003, Stas Bekman wrote: > Perrin Harkins wrote: >> On Tue, 2003-07-29 at 07:23, Stas Bekman wrote: >> >>>That's correct. This is because $r->chdir_file in compat doesn't do >>>anything. The reason is that under threaded mpm, chdir() affects all >>>threads. Of course we could check whether the mpm is prefork and do >>>things the old way, but that means that the same code won't work the >>>same under threaded and non-threaded mpms. Hence the limbo. Still >>>waiting for Arthur to finish porting safecwd package, which should >>>resolve this problem. >> >> When he does finish it, won't we make the threaded MPM work just like >> this? It seems like it would be reasonable to get prefork working >> properly, even if the threaded MPM isn't ready yet. > > It's a tricky thing. If we do have a complete implementation then it's > cool. If not then we have a problem with people testing their code on > prefork mpm and then users getting the code malfunctioning on the > threaded mpms. > > I think we could have a temporary subclass of the registry (e.g.: > ModPerl::RegistryPrefork) which will be removed once the issue is > resolved. At least it'll remind the developers that their code won't > work on the threaded mpm setups. However if they make their code > working without relying on chdir then they can use Modperl::Registry > and the code will work everywhere.
What's wrong with having the chdir code check for the threaded mpm, and, if it detects it, generate a warning that describes the situation? Admittedly, I have a difficult time understanding someone who tests under one mpm, and then releases under another mpm without testing. I realize there are people who do this sort of thing; I'm merely stating that I have difficulty understanding them. Ed
