Resource limits for Haskell

[Edward Z. Yang]

Excerpts from Alexander Kjeldaas's message of Fri Mar 08 01:32:50 -0800 2013:
> Regarding "timely", can this be exploited by a Safe Haskell "tenant" to
> obstruct invocation of the listener to exceed resource limits?  Are there
> any guarantees that can be given?

With the current scheduler implementation, the tenant will get at most one
more scheduled quantum to use lots of resources before the listener actually
manages to kill it.  If you are working with soft limits, this might be good enough.

> Here are some random thoughts:
> During a GC, maybe the thunk attached to the cost centre stack could be put
> behind the listener on the same capability.

Yes. Actually, it's simpler than that; just put the listener in the front
of the queue. You will be sad if the listener takes too long to figure out what
to do though!

> Or with the tickets system, maybe the listener could steal tickets from the
> thunk at every GC until it has executed, or something like that.

Yes, this is a good synergy with stride scheduling.  An even simpler measure
is to give the listener max number of tickets, so it will get scheduled before
the tenant.

> Or a thunk could be associated with an allocation budget, independent of
> the resident size, and when the allocation budget is exceeded, it will
> block on an MVar.  The listener/monitor has to run to increase the
> allocation budget.

This would correspond to the ability to "freeze" Haskell threads in
mid-execution; no MVar blocking necessary.  This is not possible with
the current RTS. I don't know how hard it would be to do.

Edward