From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel,gmane.lisp.guile.user Subject: About cleaning up the thread stuff Date: Tue, 18 Jan 2005 16:54:43 +0100 Message-ID: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1106064565 19263 80.91.229.6 (18 Jan 2005 16:09:25 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 18 Jan 2005 16:09:25 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Jan 18 17:09:09 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Cqvun-0007Cu-00 for ; Tue, 18 Jan 2005 17:09:09 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cqw6g-0006eA-O6 for guile-devel@m.gmane.org; Tue, 18 Jan 2005 11:21:26 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Cqw4x-0006ET-5Y for guile-devel@gnu.org; Tue, 18 Jan 2005 11:19:39 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Cqw4k-0006Ba-VB for guile-devel@gnu.org; Tue, 18 Jan 2005 11:19:27 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cqw4k-000654-Ip; Tue, 18 Jan 2005 11:19:26 -0500 Original-Received: from [129.217.163.1] (helo=mail.dt.e-technik.uni-dortmund.de) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cqvgr-0001AB-Ls; Tue, 18 Jan 2005 10:54:46 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id 0BAF14EDE2; Tue, 18 Jan 2005 16:54:45 +0100 (CET) Original-Received: from mail.dt.e-technik.uni-dortmund.de ([127.0.0.1]) by localhost (krusty [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30004-01-2; Tue, 18 Jan 2005 16:54:44 +0100 (CET) Original-Received: from troy.dt.e-technik.uni-dortmund.de (troy.dt.e-technik.uni-dortmund.de [129.217.163.17]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id 745474EDCD; Tue, 18 Jan 2005 16:54:44 +0100 (CET) Original-Received: by troy.dt.e-technik.uni-dortmund.de (Postfix, from userid 520) id E24D6B9AC; Tue, 18 Jan 2005 16:54:43 +0100 (CET) Original-To: guile-user@gnu.org, guile-devel@gnu.org User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux) X-Virus-Scanned: by amavisd-new at dt.e-technik.uni-dortmund.de X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:4693 gmane.lisp.guile.user:4108 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:4693 Hi, I am now turning to go over the thread stuff in Guile, first to understand what we have, and then to maybe clean it up and document it authoritatively. I'd like to give you advance warning of where I am heading at the moment so that you can talk me out of doing the wrong things. All of this might change as I make up my mind, but please comment anyway. I do the work on the 'branch_mvo-thread-cleanup' branch. - First, I want to rip out the plugin interface since it confuses me a bit. Maybe I'll put it back in later, but to get started, I only want to deal with POSIX pthreads. Guile will be able to use pthreads, but can also be compiled without pthreads. I consider the pthread API to be the plugin interface where different threading implementations can be selected. Maybe it is useful to make the names configurable that Guile uses for the pthread API, but it should always be a pthread API. - Then I want to specify clearly the two modes that a program can be in: 'guile mode' and 'non-guile mode'. In guile mode, a program can use functions from the Guile API and must play by the rules of Guile, in non-guile mode, it can not call Guile functions (safe a very few exceptions) but does not need to play by the rules. The rules are basically that a thread must periodically execute SCM_TICK and must only block in functions provided by Guile. If you want to block in other ways, you must first leave guile mode (and enter again after blocking). Stack frames that are created in non-guile mode are not scanned by the GC so you can not store SCM values in them. You can enter guile mode in any thread, but Guile offers convenience functions for creating threads that start out in Guile mode. When a thread first enters guile mode, it gets a 'guile personality' and shows up in (all-threads), for example. When it leaves guile mode, it keeps this personality and is only removed from (all-threads) when it terminates. - For Scheme (and also for C code that wants to use them), I want to offer 'fat' mutexes and condition variables. These are mutexes and condvars that are as nice as reasonable: they are fair, you can query easily where threads are blocking, asyncs are handled while blocking, dead-locks might be detected and mutexes can be recursive, for example. No other kinds of mutexes are offered, for example, all mutexes used by Scheme code will be of this 'fat' kind. (The low level C API will disappear.) If you want to use pthread mutexes, you can, but you must leave guile mode while blocking on them. To make this easy, there will be functions like scm_pthread_mutex_lock that is just like pthread_mutex_lock but will properly leave guile mode while blocking. (The only advantage that pthread mutexes have over these 'fat' ones is that they are slightly faster and slightly smaller. I don't consider these reasons good enough to lose the advantages of the fat ones.) _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel