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 Subject: Re: future thread interface Date: 01 Jul 2003 12:27:07 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <87vfumtudg.fsf@zagadka.ping.de> References: <20030701013250.A12964@kiwi.pyrotechnics.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1057055732 29054 80.91.224.249 (1 Jul 2003 10:35:32 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 1 Jul 2003 10:35:32 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Jul 01 12:35:30 2003 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 19XITy-0007YI-00 for ; Tue, 01 Jul 2003 12:35:30 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19XIPc-0001YD-GA for guile-devel@m.gmane.org; Tue, 01 Jul 2003 06:31:00 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19XIMm-0000Y0-Au for guile-devel@gnu.org; Tue, 01 Jul 2003 06:28:04 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19XIMN-0000R8-TB for guile-devel@gnu.org; Tue, 01 Jul 2003 06:27:41 -0400 Original-Received: from [129.217.163.6] (helo=zagadka.ping.de) by monty-python.gnu.org with smtp (Exim 4.20) id 19XIM3-0000EF-KD for guile-devel@gnu.org; Tue, 01 Jul 2003 06:27:19 -0400 Original-Received: (qmail 29591 invoked by uid 1000); 1 Jul 2003 10:27:08 -0000 Original-To: Christopher Cramer In-Reply-To: <20030701013250.A12964@kiwi.pyrotechnics.com> Original-Lines: 48 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 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:2585 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2585 Christopher Cramer writes: > 1. The goal is to be able to pick between different thread > implementations. When is this choice actually supposed to be made: compile > time, link time, during Guile startup, or when? Right now (looking at CVS) > it's compile time, but it looks like the goal is during Guile startup; > It just doesn't seem to be stated anywhere. In my view, the goal is to avoid to have to chose. That is, Guile should be written against the POSIX pthread API only. When people have a need for a non-standard threading implementation, that implementation should offer the pthread API and Guile can then use it transparently. We offer one such pthread-'ersatz' implementation with Guile: null-threads. This implementation is used on platforms that don't have pthreads. Null-threads do not offer real threading, but the API is there and you can write your code in a thread-aware fashion even when no threads can ever be created. > 2. The prevailing view is apparently that at some point in time > coop thread support will be completely dropped. When is this going > to happen? This depends on what you mean exactly with "coop" threads. The coop thread package based on QuickThreads has already been removed from 1.7. But Guile is still using cooperative threading, to a degree. It needs all Guile-using threads to cooperate during a GC, for example. This kind of cooperation will likely be with us for a long time, and probably forever. The reason for this is that a concurrent GC leads to a much more complicated programming model. > Personally I would like to keep using coop threads until pthreads on > Linux/glibc gets much more efficient than it is now. The 'new' way is to code a cooperative package that offers a pthread API. Then we can make sure that Guile can use it. > 3. A while ago I was working on a patch to eliminate all the blocking > caused by accept/connect/etc. If I finish it now, can it possibly included > in 1.6.5 (or in 1.6.x at all), or should I target the patch for 1.7? I don't see such a large patch going into 1.6. Please concentrate on 1.7. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel