[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: |
Alaric Snell-Pym |
Subject: |
Re: [Chicken-hackers] Minutes of 2012-06-14 IRC meeting |
Date: |
Tue, 19 Jun 2012 10:21:01 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 |
-----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.
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?
ABS
- --
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk/gRH0ACgkQRgz/WHNxCGpSrwCeLsB6QMBDdTbtxjD1RLMd8dgV
X/0AniD0Lr1tTyNQIZ0aygshH2NVOtyp
=xi0N
-----END PGP SIGNATURE-----