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: SCM_DEFER_INTS versus error Date: Mon, 22 Sep 2003 20:10:38 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <87oexcd78h.fsf@zagadka.ping.de> References: <87el0028c2.fsf@zip.com.au> <87ekyf9g50.fsf@zagadka.ping.de> <87r82bxbx0.fsf@zip.com.au> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1064254515 17314 80.91.224.253 (22 Sep 2003 18:15:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 22 Sep 2003 18:15:15 +0000 (UTC) Cc: Mikael Djurfeldt Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Sep 22 20:15:13 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1A1VDN-0007nJ-00 for ; Mon, 22 Sep 2003 20:15:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.22) id 1A1VBv-0001nb-St for guile-devel@m.gmane.org; Mon, 22 Sep 2003 14:13:43 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.22) id 1A1VAY-0001Ag-4R for guile-devel@gnu.org; Mon, 22 Sep 2003 14:12:18 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.22) id 1A1VAV-00018x-To for guile-devel@gnu.org; Mon, 22 Sep 2003 14:12:16 -0400 Original-Received: from [129.217.163.1] (helo=mail.dt.e-technik.uni-dortmund.de) by monty-python.gnu.org with esmtp (Exim 4.22) id 1A1V8y-0000Ve-EF for guile-devel@gnu.org; Mon, 22 Sep 2003 14:10:40 -0400 Original-Received: from zagadka.ping.de (unknown [192.168.2.2]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with SMTP id 8006C70C5 for ; Mon, 22 Sep 2003 20:10:39 +0200 (CEST) Original-Received: (qmail 17451 invoked by uid 1000); 22 Sep 2003 18:10:38 -0000 Original-To: guile-devel@gnu.org In-Reply-To: <87r82bxbx0.fsf@zip.com.au> (Kevin Ryde's message of "Sun, 21 Sep 2003 09:44:43 +1000") User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:2817 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2817 Kevin Ryde writes: > Marius Vollmer writes: >> >> Right now (if I'm still uptodate), only one thread can >> execute 'in Guile', > > Oh, I thought you'd said previously there could be concurrent such > threads. (I'd meant to try to work up a section for the manual on > such things.) What are you referring to precisely? We do use concurrent threads, but we (currently) restrict them to cooperate so that only one of them has access to Guile data structures at any one time. (We have the equivalent of the Big Kernel Lock.) When a thread might block or has executed long enough, it leaves Guile-mode temporarily, allowing the next thread to execute. (I think. I have to admit, that I am probably not fully uptodate with the details, as Mikael has done the most work on this.) >> Yes. > > I realized since posting, that time() on a DOS system might be > affected by the TZ changes made by the other stime.c functions. > > I guess all that stuff ought to change to use a little mutex > controlling access to TZ. getenv/putenv would have to cooperate with > that too so a mere temporary change is not seen or overridden. Blech. -- 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