From owner-freebsd-hackers Tue Mar 10 11:30:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA04907 for freebsd-hackers-outgoing; Tue, 10 Mar 1998 11:30:00 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA04677 for ; Tue, 10 Mar 1998 11:29:17 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id MAA07876; Tue, 10 Mar 1998 12:29:08 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpd012269; Mon Mar 9 22:04:36 1998 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id WAA29198; Mon, 9 Mar 1998 22:04:32 -0700 (MST) From: Terry Lambert Message-Id: <199803100504.WAA29198@usr09.primenet.com> Subject: Re: Perl, Threads, FreeBSD, High Weirdness To: chris@netmonger.net (Christopher Masto) Date: Tue, 10 Mar 1998 05:04:32 +0000 (GMT) Cc: perl5-porters@perl.com, nvp@mediaone.net, hackers@FreeBSD.ORG In-Reply-To: <19980309152332.35831@netmonger.net> from "Christopher Masto" at Mar 9, 98 03:23:32 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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