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

[Felix]

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

> -----BEGIN PGP SIGNED MESSAGE-----
> 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
>>> http://www.cs.arizona.edu/projects/sumatra/hallofshame/monitor-finalizer.html
>>> (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. 

cheers,
felix