[Ecls-list] Resitricted mode - possible?

[Matthew Mondor]

On Tue, 13 Nov 2012 12:38:11 +0100
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at gmail.com> wrote:

> Dear Peter,
> 
> I would appreciate if, instead of directing the questions to my private
> email, you would send them to the mailing list for future use of other
> people. This is not a private consulting office and if I answer some
> question to you, it is most likely that I will have to answer the same
> question again.
> 
> On Tue, Nov 13, 2012 at 11:32 AM, Peter Enerccio <enerccio at gmail.com> wrote:
> 
> > Okay, the only limitations that I somehow need is the memory allocation
> > limit. Is that possible
> 
> somehow in ecl?
> >
> 
> Please read
> http://ecls.sourceforge.net/new-manual/ch28.html
> They can be established, but it is hard to work with them for simple
> reasons: when such an error happens, it is likely to affect other threads.
> More precisely, the limits cannot be set on a per-thread basis and if one
> thread triggers it, no other thread will be able to allocate more memory
> and will also trigger an error.

Indeed, to implement this you'd need a custom wrapper around the
allocation functions (boehm for instance), or custom boehm-gc
modifications.  Still, anything used via FFI could potentially still
allocate things in a way that would be difficult to control.

In general, if you need to enforce permission, allocation and executon
time limits, it would be better if you could use full processes (those
may be chrooted, run under the wanted permissions, use setrlimit, and
may be recycled-restarted regularily if they're allowed to serve more
than one request (for performance reason to avoid constant fork and
lisp context setup, restarting would allow to free leaked resources),
and an RPC style system would be used to send requests and retreive
results, possibly using s-exp, json, xml or a custom binary
representation)...

Of course the problem in this case becomes shared resources, especially
ones which may be too large to easily pass as messages, if those are
needed.  A database could be used, files with advisory locks, and/or a
custom system around mmap(2), sysvshm etc.
-- 
Matt