guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SCM_DEFER_INTS versus error


From: Marius Vollmer
Subject: Re: SCM_DEFER_INTS versus error
Date: Mon, 22 Sep 2003 20:10:38 +0200
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

Kevin Ryde <address@hidden> writes:

> Marius Vollmer <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]