threads question
Alan Burlison
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
--
Elizabeth Mattijsen
>Why was it thought that exiting a scope was a good mechanism for
>releasing locks, rather than an explicit unlock?
I have no idea. It forced me to have to use XS for forks.pm... ;-)
Liz
Alan Burlison
>> Why was it thought that exiting a scope was a good mechanism for
>> releasing locks, rather than an explicit unlock?
>
> I have no idea. It forced me to have to use XS for forks.pm... ;-)
IMHO it's far to constraining, and is a design mistake.
--
Alan Burlison
--
Elizabeth Mattijsen
Well, maybe Perl 6 will do a better job... ;-) If you want to make
sure the underlying system will allow for what you want, you might
want to follow the threads discussions on perl6-internals aka parrot.
;-)
Liz
Alan Burlison
> Well, maybe Perl 6 will do a better job... ;-) If you want to make
> sure the underlying system will allow for what you want, you might want
> to follow the threads discussions on perl6-internals aka parrot. ;-)
I fully expect to be retired before perl6 sees the light of day ;-)
--
Alan Burlison
--
Elizabeth Mattijsen
Well, I expected to retire 3 years ago. Then the internet bubble
deflated just a little too soon...
;-(
Liz
Dave Mitchell
Well, for the cases where the constraints don't get in the way, it
provides useful semantics; it means that the variable is unlocked no
matter how the scope is exited (eg eval{} and die), and you can lock
multiple times with the lock only becoming unlocked when the outermost
scope is exited.
The docs for lock in shared.pm suggest:
Note that you cannot explicitly unlock a variable; you can only wait
for the lock to go out of scope. If you need more fine-grained
control, see L<Thread::Semaphore>.
Is Thread::Semaphore suitable for your needs, or do you think
that threads::shared needs an extra set of (non-scoped) lock functions?
Dave.
--
"I do not resent critisism, even when, for the sake of emphasis,
it parts for the time with reality".
-- Winston Churchill, House of Commons, 22nd Jan 1941.
Dave Mitchell
> 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:
See change below.
--
The optimist believes that he lives in the best of all possible worlds.
As does the pessimist.
Change 22257 by davem@davem-percy on 2004/02/01 15:46:24
threads documentation: fork on UNIX might not copy all threads.
Affected files ...
... //depot/perl/pod/perlthrtut.pod#29 edit
Differences ...
==== //depot/perl/pod/perlthrtut.pod#29 (text) ====
@@ -985,9 +985,10 @@
changing uids/gids.
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.)
+until the feeling passes. Be aware that the semantics of fork() vary
+between platforms. For example, some UNIX systems copy all the current
+threads into the child process, while others only copy the thread that
+called fork(). You have been warned!
Similarly, mixing signals and threads should not be attempted.
Implementations are platform-dependent, and even the POSIX
Alan Burlison
> Well, for the cases where the constraints don't get in the way, it
> provides useful semantics; it means that the variable is unlocked no
> matter how the scope is exited (eg eval{} and die), and you can lock
> multiple times with the lock only becoming unlocked when the outermost
> scope is exited.
All this is true - I'm sure in the majority of cases it works fine.
However, it isn't *always* what you want.
> The docs for lock in shared.pm suggest:
>
> Note that you cannot explicitly unlock a variable; you can only wait
> for the lock to go out of scope. If you need more fine-grained
> control, see L<Thread::Semaphore>.
>
> Is Thread::Semaphore suitable for your needs, or do you think
> that threads::shared needs an extra set of (non-scoped) lock functions?
I think an extra set of functions would be nice, or possibly a pragma to
turn auto-unlocking off.
--
Alan Burlison
--
Alan Burlison
>>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:
>
> See change below.
That looks suitably vague and frightening :-)
--
Alan Burlison
--
Arthur Bergman
On 4 Feb 2004, at 09:48, Alan Burlison wrote:
>
> I think an extra set of functions would be nice, or possibly a pragma
> to turn auto-unlocking off.
>
>
This will happen someone sees it fit to implement this, I sure don't.
Arthur