> On Sun, Sep 09, 2001 at 04:49:50PM -0400, Barrie Slaymaker wrote:
> >
> > > However, should threads have different cwds?
> >
> > Well, if you want to use any modules that chdir() in threaded code, I
> > think so. Basically, in a threaded perl, unsafe chdir should be warned
> > about or perl should DWIM and emulate chdir per thread (as it does on
> > windows). The former is the halting problem, I think ;-).
>
> Also, %ENV should probably be thread-localized if it's not, for similar
> reasons.
>
> When Java's designers faced this problem, they just said "thou shalt not
> chdir()". Well, that's one way to do it, or you can be nice and have
> your language say "well, it'll slow things down, but go ahead". The
> only problem I have is that it slows things down whether or not you use
> it (since, for instance, open() needs to at least check the actual dir
> against the current thread's emulated cwd and perhaps do a chdir()
> C RTL call before the open() C RTL call. Or something. But there could
> always be a "don't emulate chdir-per-thread" option, either when
> building perl or at runtime...
>
> - Barrie
>
This could potentially be fixed by an external module which hooks into
CORE::GLOBAL::chdir and CORE::GLOBAL::open.
ENV suffers from the same problems I agree. (But ENV cannot be solved by a module).
It could easily be a runtime option, or it could be implmented using iperlsys stuff.
However writing a iperlsys layer
is not trivial, and is probably a bigger slowdown than adding the proper code to open.
I also would hardly consider chdir+open
to be a hotspot in any larger program.
Arthur
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
