From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: Thread interface issues (was Re: C level mutices and condition variables) Date: 12 Nov 2002 23:09:57 +0000 Sender: guile-devel-admin@gnu.org Message-ID: References: <87vg3pot7a.fsf@zagadka.ping.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1037145273 22492 80.91.224.249 (12 Nov 2002 23:54:33 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 12 Nov 2002 23:54:33 +0000 (UTC) Cc: Marius Vollmer , djurfeldt@nada.kth.se 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 18BkrU-0005q2-00 for ; Wed, 13 Nov 2002 00:54:28 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18Bkn4-00089O-00; Tue, 12 Nov 2002 18:49:54 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18BkDh-0005mF-00 for guile-devel@gnu.org; Tue, 12 Nov 2002 18:13:21 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18BkDe-0005lS-00 for guile-devel@gnu.org; Tue, 12 Nov 2002 18:13:20 -0500 Original-Received: from mail.uklinux.net ([80.84.72.21] helo=s1.uklinux.net) by monty-python.gnu.org with esmtp (Exim 4.10) id 18BkDd-0005ke-00 for guile-devel@gnu.org; Tue, 12 Nov 2002 18:13:17 -0500 Original-Received: from laruns.ossau.uklinux.net (bts-0477.dialup.zetnet.co.uk [194.247.49.221]) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id gACNDCD25302; Tue, 12 Nov 2002 23:13:13 GMT Original-Received: from laruns.ossau.uklinux.net.ossau.uklinux.net (localhost [127.0.0.1]) by laruns.ossau.uklinux.net (Postfix on SuSE Linux 7.2 (i386)) with ESMTP id 81AFEDC12B; Tue, 12 Nov 2002 23:09:57 +0000 (GMT) Original-To: guile-devel@gnu.org In-Reply-To: Original-Lines: 74 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:1696 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1696 >>>>> "Mikael" == Mikael Djurfeldt writes: [summary of thread issues and why he wants a C thread API :-)] Oh dear. Having supported Marius' proposal earlier, I now find Mikael's arguments quite persuasive. So I will try to help by summarizing the point of disagreement, then revisit the earlier conversation where Marius persuaded me of his proposal. (FWIW, I did have a few second thoughts about removing scm_t_mutex even before Mikael raised questions, when something that ttn said on guile-user reminded me of past arguments ...) So, the gist. MDJ wants a C API (with a Scheme API on top of it) for - back compatibility - performance - similarity to pthreads interface. MVO prefers a Scheme API that is callable from C for - ability to put SCM data inside mutexes etc. without worrying about GC - because static declaration of scm_t_mutex needs to change anyway. Revised notes on our earlier conversation: >> Neil Jerram writes: >> >> > - Why would you want "to have SCM data in a scm_t_mutex"? - isn't the >> > data that you are protecting access to normally a separate variable >> > (or set of variables) from the mutex itself? >> >> I was thinking about data that is needed to implement the mutex >> itself. It would be nice to be able to use SCM values, I'd say, just >> because a SCM string as the mutex name is nicer than a C string. 2nd thoughts: why does a mutex need a name? Didn't we recently remove names from variables because they were unSchemely? >> Concretely, I wanted to use SCM lists to implement the waiting queue >> (to add fairness to POSIX mutices), mostly because SCM lists are >> already there and why shouldn't I use them then? Given the renewed discussion, could we not have both - a low level, implementation-dependent scm_t_mutex, with no fairness guarantees, that is as native as possible w.r.t. the thread impl - fair SCM mutexes built on top of scm_t_mutex. >> > - What do you mean by not abstract enough? >> >> You will declare scm_t_mutex variables and thus the size of the >> scm_t_mutex structure can not change. When we want to select mutex >> implementations at run-time, that might be a (small) problem. If we keep scm_t_mutex after all, it would be nice if existing applications didn't have to change their code. If it is already a requirement to call scm_mutex_init, couldn't scm_t_mutex have a pointer to some other structure that was dynamically allocated by scm_mutex_init? >> In any >> case, I think it is better to hide mutices behind SCM values, just as >> other data structures. This may be the key point. What other structures in Guile are most like mutexes for the purposes of this comparison? Why are mutexes not like integers, which are represented by both int and SCM? If mutexes are most like other SCM types, is it the possibility of multiple underlying thread implementations that motivates a non-SCM-based C API for them? Why don't we have the possibility (or problem) of multiple XXX implementations for other kinds of XXX in Guile? (All genuine questions.) Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel