-----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----- _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
