[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:47:37 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110617 Thunderbird/3.1.11

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


- --
Alaric Snell-Pym
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


reply via email to

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