Front page | perl.perl5.porters |
Postings from January 2004
threads question
Thread Next
From:
Alan Burlison
Date:
January 25, 2004 07:25
Subject:
threads question
Message ID:
4013DFA9.5030008@sun.com
Why was it thought that exiting a scope was a good mechanism for releasing
locks, rather than an explicit unlock?
Also, perlthrtut says this:
Thinking of mixing fork() and threads? Please lie down and
wait until the feeling passes-- but in case you really want
to know, the semantics is that fork() duplicates all the
threads. (In UNIX, at least, other platforms will do
something different.)
That isn't true on Solaris if you are linked against libpthread (perl is),
and isn't true at all in the next release of Solaris - fork() has been
changed to have fork1() semantics:
In Solaris 10, a call to fork() is identical to a call to
fork1(); only the calling thread is replicated in the child
process. This is the POSIX-specified behavior for fork().
In previous releases of Solaris, the behavior of fork()
depended on whether or not the application was linked with
the POSIX threads library. When linked with -lthread
(Solaris Threads) but not linked with -lpthread (POSIX
Threads), fork() was the same as forkall(). When linked
with -lpthread, whether or not also linked with -lthread,
fork() was the same as fork1().
In Solaris 10, neither -lthread nor -lpthread is required
for multithreaded applications. The standard C library pro-
vides all threading support for both sets of application
programming interfaces. Applications that require
replicate-all fork semantics must call forkall().
POSIX-compliant implementations should not use forkall() semantics, so the
statement in perlthrtut is incorrect.
--
Alan Burlison
--
Thread Next
-
threads question
by Alan Burlison