From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.user,gmane.lisp.guile.devel Subject: About removing the low level thread API Date: Thu, 03 Mar 2005 17:20:23 +0100 Message-ID: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1109867399 16075 80.91.229.2 (3 Mar 2005 16:29:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 3 Mar 2005 16:29:59 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Mar 03 17:29:59 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D6szp-0002nE-SM for guile-user@m.gmane.org; Thu, 03 Mar 2005 17:16:18 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D6tIp-0002Bf-5V for guile-user@m.gmane.org; Thu, 03 Mar 2005 11:35:55 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D6tIU-00026q-6o for guile-user@gnu.org; Thu, 03 Mar 2005 11:35:34 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D6tIT-00026W-ID for guile-user@gnu.org; Thu, 03 Mar 2005 11:35:33 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D6tIR-00025Q-GR; Thu, 03 Mar 2005 11:35:31 -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 1D6t3q-0005cl-0q; Thu, 03 Mar 2005 11:20:26 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id 6B5C744024; Thu, 3 Mar 2005 17:20:25 +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 29987-02-2; Thu, 3 Mar 2005 17:20:24 +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 CAA4F44023; Thu, 3 Mar 2005 17:20:24 +0100 (CET) Original-Received: by troy.dt.e-technik.uni-dortmund.de (Postfix, from userid 520) id D8C62B9A5; Thu, 3 Mar 2005 17:20:23 +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-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org X-MailScanner-To: guile-user@m.gmane.org Xref: main.gmane.org gmane.lisp.guile.user:4275 gmane.lisp.guile.devel:4817 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:4817 Hi, I am not completely happy about having removed the low level thread API. I do think that it is not the job of Guile to provide such a thing and I also found its presence to be confusing, when compared with the 'regular' thread API. On the other hand, Guile itself both works on systems that do provide a pthread API, and on systems that do not. C code written for Guile might want to support both cases as well (being properly thread safe by default, but still compilable even when the pthread API is not available). So, since Guile has already solved the problem of adapting itself to a non-pthread system via a very thin layer, it might just as well export this mechanism so that C code written for Guile does not need to provide that layer on its own. (That layer would be very much like the pthreads API. On a pthread system, it would map directly to the real pthread functions, on a pthread-less system, it would mostly be noops.) The argument against this would be that such a thin adaptation layer, once exported, needs to be complete enough to be useful and we need to maintain it. We might not want to worry about this, since, well, it is not the job of Guile to provide an alternative to pthreads. More conretely, we had the following functions: - SCM scm_lock_mutex (SCM mutex) Locks a Scheme-level mutex. Same as 'lock-mutex' in Scheme. - int scm_mutex_lock (scm_t_mutex *mutex) Locks a low-level mutex. I want to remove scm_mutex_lock (and all other functions in the low-level API) and maybe, just maybe, provide instead - int scm_p_pthread_mutex_lock (scm_p_pthread_mutex_t *mutex) Identical to pthread_mutex_lock on systems with pthreads and when Guile has been configured --with-thtreads; otherwise, does nothing and always returns 0. Would you say that such alias for the pthreads API is useful? Guile needs it internally anyway, but when we do not export it, we can just implement what we need and can change it at will, of course. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user