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:47:37 +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: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-----



reply via email to

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