Resource limits for Haskell
Edward Z. Yang
ezyang at MIT.EDU
Fri Mar 8 11:13:18 CET 2013
Excerpts from Alexander Kjeldaas's message of Fri Mar 08 02:06:07 -0800 2013:
> > 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!
> With this scheduling trick, it seems that it should be possible to
> guarantee that at most one scheduled quantum + one nursery of memory is
> used. (The non-allocating process is still a problem if I understand
Well, that's why you compile with -falways-yields http://hackage.haskell.org/trac/ghc/ticket/367
> Another API semantics that comes to mind is limit the resident size in a
> tree-like fashion so that whoever does forkIO will get the child resident
> size attached to his own process. This requires a listener to be able to
> kill off whole process-trees (think cgroups in linux).
This is a little more difficult, because I do not know how to do inherited
resource counts efficiently. (The profiler does do them, but only at the
*end* of the process, and it involves walking all of the stacks.) It may
still be worth implementing.
> > 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.
> Random idea: Maybe there could be a never-executed capability in the RTS.
> Schedule the frozen process on that capability. This seems to be doable
> from the RTS side of things. When some condition arises, schedule it on
> the frozen capability. Then notify something in Haskell land. I don't
> know how to do the notification - when I looked at notifying through MVars
> for the event log it wasn't as easy as pie.
That would be pretty cute implementation strategy; freezing and unfreezing
corresponds to moving process on and off the cap. Of course, why not just
dispense with the entire capability and just have a list of frozen TSOs?
More information about the ghc-devs