Simon mentioned a system of doing multiple GC's to measure actual live data. But wouldn't a more limited alternative be capping *allocation* rather than live data? GHC already has an mechanism to preempt IO threads based on an allocation trip wire. In fact that's *the* preemption mechanism. Isn't the only piece missing to have a primitive similar to chez Scheme's "make-engine": http://www.scheme.com/csug8/control.html#./control:s13 ... which would transfer control to a child computation, but would return control to the parent (along with a continuation) when its allocation budget is exhausted? Make-engine + safe-haskell + timeouts should be everything one needs to resist an adversarial untrusted program. Maybe? -Ryan P.S. Chez Scheme engines are actually related to # procedure calls, not allocation as far as I know. On Fri, Apr 20, 2012 at 7:35 PM, Edward Z. Yang <ezyang@mit.edu> wrote:
Excerpts from Brandon Allbery's message of Fri Apr 20 19:31:54 -0400 2012:
So, it would be pretty interesting if we could have an ST s style mechanism, where the data structure is not allowed to escape. But I wonder if this would be too cumbersome for anyone to use.
Isn't this what monadic regions are for?
That's right! But we have a hard enough time convincing people it's worth it, just for file handles.
Edward
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users