From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.devel Subject: Warning: Unstable POSIX threads support comitted to CVS Date: Mon, 09 Dec 2002 14:44:47 +0100 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: Reply-To: Mikael Djurfeldt NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: main.gmane.org 1039444605 30898 80.91.224.249 (9 Dec 2002 14:36:45 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 9 Dec 2002 14:36:45 +0000 (UTC) Cc: marius.vollmer@uni-dortmund.de Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18LP1X-00082C-00 for ; Mon, 09 Dec 2002 15:36:43 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18LOEl-0006hP-06 for guile-devel@m.gmane.org; Mon, 09 Dec 2002 08:46:19 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18LODO-0006bU-00 for guile-devel@gnu.org; Mon, 09 Dec 2002 08:44:54 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18LODL-0006aO-00 for guile-devel@gnu.org; Mon, 09 Dec 2002 08:44:53 -0500 Original-Received: from kvast.blakulla.net ([213.212.20.77]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18LODL-0006Zi-00 for guile-devel@gnu.org; Mon, 09 Dec 2002 08:44:51 -0500 Original-Received: from barbara.blakulla.net ([213.212.21.238] helo=linnaeus) by kvast.blakulla.net with esmtp (Exim 3.36 #1 (Debian)) id 18LODI-0003Pd-00; Mon, 09 Dec 2002 14:44:48 +0100 Original-Received: from mdj by linnaeus with local (Exim 3.36 #1 (Debian)) id 18LODH-00064p-00; Mon, 09 Dec 2002 14:44:47 +0100 Original-To: guile-devel@gnu.org Original-cc: djurfeldt@nada.kth.se X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:1809 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1809 --=-=-= Hi, Based on Marius copt threads work, I've now put together an initial version of full POSIX threads support with preemptive thread scheduling. This is especially good to have if you, like me, use multi-cpu machines. Attached to this letter is an example program: par-fib N DEPTH --> fibonacci number N The number is computed by forking to DEPTH levels. For example, (par-fib 100 4) creates 31 threads (with 16 threads at the base level, reverting to iterative computation of the rest). (par-fib 100 5) crashes for me... :) Well, yes, the current state of the code is slightly broken. Just as before this change, the null-threads alternative won't build, and the threading alternative is the default. The idea is that we for the coming couple of weeks can make a collaborative effort of finding bugs and fundamental problems. However, single-thread use seems stable (although there could be some problems with errors in macro transformers). We need to work on signal delivery and exceptions. One suggestion is that we continue to *only* deliver signals at SCM_ASYNC_TICK points. The effect of signal delivery (normally a throw) is then pretty well controlled. A novel (?) suggestion is this: It is very irritating that signals are delivered to whatever thread happens to run for the moment. Is it possible to add explicit interactive control over which thread is the "foreground" thread? Only the "foreground" thread gets signal delivery (=> that thread gets its async lists marked regardless of which thread reacted on the signal). Normally, the "foreground" is the repl loop thread, and we can have a small "command language" (perhaps ordinary scheme procedures) to inspect status of the other threads and explicitly deliver signals like "SIGINT". One further area which needs work is the current recursive critical sections (SCM_REDEFER/REALLOW_INTS, SOURCE_SECTION in eval.c etc). They need to be optimized (use real POSIX recursive mutecis if available). We should also add a mechanism for resetting (unlocking) the associated mutecis on an error throw. This can be made by adding a line for registering the critical section in SCM_REC_CRITICAL_SECTION in snarf.h. I and Marius hope to fix the most basic problems within a few days. Then I think we'll have an acceptable level of stability. And, as Marius have said before, the thread suppport is in a state of flux. Much can still change... (BTW, there seems to be some unrelated build problem right now due to the recent change to versioning.) Best regards, Mikael D. --=-=-= Content-Disposition: attachment; filename=fib.scm Content-Description: Thread test program (define (par-fib n n-forks) (cond ((<= n 1) 1) ((> n-forks 0) (letpar ((f1 (par-fib (- n 1) (- n-forks 1))) (f2 (par-fib (- n 2) (- n-forks 1)))) (+ f1 f2))) (else (let ((f1 (mono-fib (- n 1))) (f2 (mono-fib (- n 2)))) (+ f1 f2))))) (define (mono-fib n) (let iter ((f1 1) (f2 1) (i 1)) (if (>= i n) f2 (iter f2 (+ f1 f2) (+ 1 i))))) --=-=-= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel --=-=-=--