On Sun, Sep 09, 2001 at 02:10:51PM +0800, Stas Bekman wrote:
> >
> > On a lot of OSs, the cwd is kept as a part of the kernel's
> > per-process structures, so all threads share the same idea of cwd.
> > Anytime you use a userland threads package this is likely.
> >
> > There are other threading prblems, like non-reentrant C RTL calls
> > and old, old APIs like, asctime(), that return pointers to static
> > buffers inside the C RTL. Perl will probably come to use reentrant
> > versions or wrap non-reentrant ones with mutexes and copy off static
> > buffers, or just disable certain calls in threaded mode, but XS code
> > is another kettle of fish. A lot of problems won't show up on
> > single CPU boxes, either, so a lot of people can't test their code
> > in SMP MT environments :-(. Let alone write t/*.t scripts that try
> > to exercise things in a MT fashion.
> >
> > Then there's APIs that are completely non threadsafe, AFAIK, like
> > setjmp/longjmp, which are used in Perl in some farily critical
> > places.
> >
> > All of the above have fixes, not sure how many are practical in
> > perl5.
>
> Argh :( Are there any pointers to read on these issues.
I wish I knew of a good "portable multithreaded programming" primer;
perhaps someone else does. Python's been up this curve, you might ask
on the language-dev list, and you might look at GNU Pth's docs and at
the various threading FAQs. Curl up with Google by the fireplace for an
evening ;-).
> Shouldn't
> these issues be transparent for the programmers using Perl? Ideally?
Ideally, yes. Perl's headed towards a shared-nothing-by-default
threading paradigm (not just in-process resources, but OS interactions
like signals have to be thought of) and has the ability to work around
(some) non-reentrant or static-buffer-using C RTL APIs and syscall
wrappers, but things like chdir() are a right pain (this will bite on every
platform where userspace threads are used, and on some (eg Netware)
where they aren't).
Perl's approach will also minimize setjmp/longjmp issues, I think, by
not trying to jump between threads. Ask Alan Berlinson for details, he
is rather strident (and needs to be) when commenting on this[1].
Anyway, the bottom line is that things like chdir() are likely to be
non-portable (ok on Linux and maybe Windows, at least, not on FreeBSD,
probably never on NetWare, for instance), most dangerous-today library
calls will have increasing levels of thread safety at noticable cost to
performancs (mutexes, baby, mutexes! [2]), and perl5 will asymtotically
approach thread-safety, perhaps even reach it on "modern" OSs.
This is all IMHO, mostly info gathered a long time ago when convincing
myself that MT coding is for specialized niches where the gain is worth
the pain.
- Barrie
[1]http:[EMAIL PROTECTED]/msg00081.html
[2]http://www.timvp.com/kojak.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
