Re: [Chicken-hackers] Minutes of 2012-06-14 IRC meeting

[Felix]

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

That's right.

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

Yup, I think we basically want the same.


cheers,
felix