-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/19/2012 10:39 AM, Felix wrote:
>> 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. Maybe, but such an entity can exist without the scheduler getting involved. >> 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. Ok, imagine I said blocking I/O, then! I suppose what I'm saying is that if we have finalizers to run, but the scheduler isn't on the scene, we can still create a dynamic context that doesn't inherit dynamic winds or parameterizations or whatever from the primordial thread and use that, while still blocking the primordial thread - rather than involving the scheduler in the core. > cheers, > felix 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/gSrkACgkQRgz/WHNxCGoMNQCeO9Jz2rBMRJirBn+uL8hiPmaW q6sAn3O+XPEVk259Fz84ntKU0Qjassus =Kc4w -----END PGP SIGNATURE----- _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
