chicken-hackers
[Top][All Lists]
Advanced

[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-----



reply via email to

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