"containing" memory-consuming computations
Ryan Newton
rrnewton at gmail.com
Mon Jul 16 20:08:35 CEST 2012
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 at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20120716/d97fc024/attachment.htm>
More information about the Glasgow-haskell-users
mailing list