Resource limits for Haskell

Alexander Kjeldaas alexander.kjeldaas at gmail.com
Fri Mar 8 10:32:50 CET 2013


On Fri, Mar 8, 2013 at 10:14 AM, Edward Z. Yang <ezyang at mit.edu> wrote:

> Excerpts from Alexander Kjeldaas's message of Fri Mar 08 01:09:27 -0800
> 2013:
> > The API has ccsDynamic, while the example uses newCostCentreStack.
>
> Oops, fixed. (Added the newCostCentreStack helper function).
>
> > Would it be possible to attach a listener to GC-events and dynamically
> > adjust the listenCostCentreStack to trigger before major GCs?
>
> Yes, but these listeners would only trigger after the GC, and have no
> guarantee of triggering in a timely fashion (e.g. before the next GC).
> Generally it's only safe to trigger "one-time" events.
>
>
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?

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.

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.

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.

Alexander


> > Is this secure in the Safe Haskell sense?  Can this be used to create a
> > secure computation wrt resources?  Could we listen to MUT seconds?
>
> That's the idea!  But we'll need semantics before we can say for sure.
> Actually, as far as time resources are concerned, the hope is to use
> this in conjunction with http://hackage.haskell.org/trac/ghc/ticket/7606
>
> Edward
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130308/a8eac6f9/attachment-0001.htm>


More information about the ghc-devs mailing list