> > I would suspect linux has a process level chdir, not sure thou.
>
> Just checked, pthread_create() causes all threads to share the cwd and
> umask. By using __clone() directly, they could be set as unshared, I
> think, by passing CLONE_FS.
So we can easily fix it for linux.
> I guess the bottom line it: Perl seems to be headed towards an emulation
> of multiprocessing (unshared everything by default); how far should it
> go in that direction? The Win32 approach has been to go as far as
> possible to emulate fork(), and I think that that's a good approach,
> since it will lead to least surprises among non-threads programmers.
> The downside is increases complexity and a corresponding performance hit
> (though I think it will usually be minor).
Yes, but we also have the issues of running under threaded perl and running
different perl programs in different threads. %ENV should be shared in the
first case, not in the second. Same with cwd.
> I think that for mod_perl backcompat purposes the more the merrier, so
> that lots of existing modules don't need to be ported to MT-safety. But
> for performance-seekers, that may not be the ideal. Of course "for
> them, there's C" might be an acceptable answer, I dunno.
I don't agree, I think it should an option in perl wheter to share these things or not?
> Things like umask, %ENV, $SIG{__DIE__}, $SIG{__WARN__}, cwd, open files,
> etc. can be copied to get really close to the "ideal", things like euid,
> uid, etc., are more difficult to play pretend with.
>
__DIE__ and __WARN__ should already be per thread. But this is a can of worm, there
are many
variables which have to be delt with. $$ for example. Not all platforms give out a
different pid for different
threads. Win32 does this by having negative pids.
However, if one wants to solve this properly, one should write a iperlsys layer for
unix.
Arthur
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
