> > 1. A thread is either resource-aware or abstracts away the details
> >     and difficulties of resource management.
> > 2. If resource availablity is high, both kinds of threads can allocate
> >     (in case of memory: implicitly, as usual in functional programs).
> > 3. If resource availability is low,
> >     - resource-aware threads receive an asynchronous exception, 
> >        but may then proceed to allocate as before 
> >        (until the resource is actually exhausted)
> >     - resource-unaware threads block on allocation attempts
 
> Which resource-aware threads will receive the exeption?

All. As the name suggests, resource-aware threads are those that
have registered an interest in details related to the resource. 
Registering interest could be implicit in setting up an exception
handler of appropriate type, but would probably better be done 
by an explicit operation:

-- input: which resources we are interested in
-- result: which resources we could not register for,
--            usually empty?
registerInterest :: [ResourceId] -> IO [ResourceId]
 
> How a handler thread can ensure that it has freed enough memory to
> unblock threads that are blocked, or that to get an exception again
> instead of reaching a hard limit and crashing?

I suggested a new resource-check operation for this. Perhaps:

data ResourceId = Memory | ..
data ResourceStatus = Ok | Low | NotAvailable

checkStatus :: ResourceId -> IO ResourceStatus

(in case of Memory, there won't be a chance to observe NotAvailable..;
to accomodate other resources and to facilitate preventive measures,
ResourceStatus should probably be refined, but adding a percentage
parameter of type Int to Ok, and perhaps to Low, should really be 
enough)

Resource-aware threads could occasionally monitor the status of
resources and steer other threads accordingly to avoid reaching the
(soft) limit (transition from Ok to Low) and the disruption caused
by this event. But if it should be reached, they will enter their 
exception handlers for more drastic measures. The basic 
handler-loop would be:

1. do something to reduce resource allocation 
    (both now and in future - the latter might require preparing a 
    reconfiguration of the thread system to employ a modified 
    algorithm; just crossing your fingers and trying again will 
    probably not do)
2. check resource status
3. repeat from 1. until good enough to continue
4. continue in modified configuration, with new handlers

Given the nature of lazy evaluation, it will in any case be tricky to
write exception handlers that do not cause inadvertent memory 
allocation themselves..

Claus



Reply via email to