Date: Tue, 10 Mar 1998 05:04:32 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: chris@netmonger.net (Christopher Masto) Cc: perl5-porters@perl.com, nvp@mediaone.net, hackers@FreeBSD.ORG Subject: Re: Perl, Threads, FreeBSD, High Weirdness Message-ID: <199803100504.WAA29198@usr09.primenet.com> In-Reply-To: <19980309152332.35831@netmonger.net> from "Christopher Masto" at Mar 9, 98 03:23:32 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Pretending the last line is fixed, this test still fails on FreeBSD
> (2.2.5-stable as of yesterday). I don't know why, but I do know that
> threads are simply not working. They do not run concurrently.
>
> This test program:
>
> use Thread;
>
> $t = Thread->new(sub { print "AAA\n" while 1; });
> while (1) {
> print "---\n";
> sleep 1;
> }
>
> Produces this output:
>
> ---
> ---
> ---
> (ad infinitum)
>
> If the main program ever performs a $t->join or exits, the AAA thread
> takes over and actually can't be stopped with a ^C or ^\ (but kill -9
> from another session works).
You are not running the most recent threads if you can't kill it
with a ^C. Jeremy fixed signal handling.
Probably it's exploding for some other reason. One candidate might
be the pthread_create attibutes which you have to pass an address
of instead of the attr.
FreeBSD's pthreads are POSIX Draft 4, not Draft 10/Release (they
are *reliably* Draft 4 after the patches that went in last month
from Jeremy and I).
If you are using code that expect Draft 10/Release, you should use
the non-existance of PTHREAD_MUTEX_INITIALIZER, like so:
#ifdef PTHREAD_MUTEX_INITIALIZER
/* POSIX Draft 10/Release threads*/
...
#else /* PTHREAD_MUTEX_INITIALIZER*/
/* POSIX Draft 4 threads*/
...
#endif /* PTHREAD_MUTEX_INITIALIZER*/
I did code for this for the STL from Moscow center for SPARC computing,
and for all of the LDAP code.
You should also know that you *must* use g++ 2.8.x if you want C++
exceptions to work with threads (the EGCS stuff will *not* work
because of the cheesy way they compile-time-of-the-compiler bound
their threading).
In general, the code is supposed to call "nanosleep" to implement
the sleep, so it should context switch at that time.
One problem you *will* have is that the AAA thread *always* has
"work to do".
The way you are *supposed* to deal with this is using a scheduler
thread at a higher priority to impose "fairness" by forcing the
thread that was running before it ran to be rescheduled. This
puts it at the end of the scheduling queue, and consequently,
the other thread runs if it got over its sleep and made it into the
queue. Otherwise your monster thread gets to run again.
If Perl is defeating this behaviour, then Perl is broken.
More likely, you are just using old threads library code, or Perl
is assuming a Draft 10/Release version of pthreads somewhere.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803100504.WAA29198>