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: Re: future thread interface Date: Sat, 05 Jul 2003 14:05:49 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: References: <20030701013250.A12964@kiwi.pyrotechnics.com> <87vfumtudg.fsf@zagadka.ping.de> Reply-To: djurfeldt@nada.kth.se NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1057406955 13274 80.91.224.249 (5 Jul 2003 12:09:15 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 5 Jul 2003 12:09:15 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Jul 05 14:09:13 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 19Ylqq-0003Rm-00 for ; Sat, 05 Jul 2003 14:09:12 +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 19Ylqu-0007mE-7j for guile-devel@m.gmane.org; Sat, 05 Jul 2003 08:09:16 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19Ylqb-0007Jf-RK for guile-devel@gnu.org; Sat, 05 Jul 2003 08:08:57 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19YlqS-0006ym-Al for guile-devel@gnu.org; Sat, 05 Jul 2003 08:08:49 -0400 Original-Received: from kvast.blakulla.net ([213.212.20.77]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19YlqG-0006WS-Td for guile-devel@gnu.org; Sat, 05 Jul 2003 08:08:37 -0400 Original-Received: from barbara.blakulla.net ([213.212.21.238] helo=witch) by kvast.blakulla.net with esmtp (Exim 3.36 #1 (Debian)) id 19YlqB-0000Fe-00; Sat, 05 Jul 2003 14:08:31 +0200 Original-Received: from mdj by witch with local (Exim 3.35 #1 (Debian)) id 19Ylna-0001Ab-00; Sat, 05 Jul 2003 14:05:50 +0200 Original-To: Marius Vollmer In-Reply-To: <87vfumtudg.fsf@zagadka.ping.de> (Marius Vollmer's message of "01 Jul 2003 12:27:07 +0200") User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) Original-cc: Christopher Cramer 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:2593 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2593 Marius Vollmer writes: > 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. I posted an analysis of the thread situation on this list before Christmas. I think you agreed with the conclusions. Although nothing you say above really contradicts what we agreed upon earlier, I wanted to post this message because one might get the impression from your message that null-threads is intended to be selected compile time only on platforms which don't have pthreads. In contrast, among the conclusions were rather the need to enable the application itself to select what thread package to use during Guile startup. I've written the latest thread code with this in mind. The API for this (threads-plugin.c) is intended to be mostly indentical with the pthreads API, as you say, but will need to contain some extra entries. Note, though, that the code is not yet complete. (I think we agreed that you would complete the null-threads part, no? :) Also, in my view, we should provide a rewritten version of COOP threads as an option for this plugin interface. (But that option should be provided in a separate dynamically loadable library, while pthreads and null threads are options provided in libguile itself.) I'll commit my thread situation analysis text to the workbook. Best regards, Mikael D. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel