[Top][All Lists]

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

Re: [Chicken-hackers] Minutes of 2012-06-14 IRC meeting

From: Felix
Subject: Re: [Chicken-hackers] Minutes of 2012-06-14 IRC meeting
Date: Tue, 19 Jun 2012 11:39:29 +0200 (CEST)

From: Alaric Snell-Pym <address@hidden>
Subject: Re: [Chicken-hackers] Minutes of 2012-06-14 IRC meeting
Date: Tue, 19 Jun 2012 10:21:01 +0100

> Hash: SHA1
> On 06/19/2012 10:00 AM, Felix wrote:
>>> Indeed they should.  In the JVM, finalizers originally ran in ordinary
>>> random threads, but there were so many problems that the design was
>>> switched to running on a separate thread.  The CLR does the same.  See
>>> (which predates the switch) for details.
>> The problem is that I would like to keep the base system thread-less
>> (with the exception of the primordial thread, naturally). We don't
>> need the scheduler until we use srfi-18. One option would be to run
>> finalizers in a separate thread once we enable threading and just run
>> them in the primordial thread if threading is not enabled yet.
> That is a workable approach; but, also, what do we mean by "thread",
> exactly?
> I think we certainly need to run the finalizers in their own *dynamic
> context*, eg with a special continuation that never leads back into
> "user code" on its own.

That is, techincally, a thread.

> And the difference between that and a *thread* is really down to what
> happens if things block. Eg, if a finalizer sleeps for a second, what
> should happen to the main line of execution?

If the finalizer sleeps using the threading-API, then the scheduler is
already loaded and we can run it in a separate thread. 


reply via email to

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