You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Ed Grimm <ja...@tgape.org> on 2003/08/07 07:12:50 UTC

Re: Working directory of script is "/" !

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



Re: Working directory of script is "/" !

Posted by Stas Bekman <st...@stason.org>.
Ed Grimm wrote:
> 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.

Here is an example: let's say that you are stuck with windows, so you can test 
only with 'winnt'.

In any case, a simple subclass of the registry does the trick for those 
running with prefork mpm and wanting the mp1 behavior. So there is no problem, 
other than communicating the solution to those who need it.


__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com