Re: scm_* API extension? [was] scm_* API question

[Marius Vollmer <marius.vollmer@uni-dortmund.de>]

rm@fabula.de writes:

> On Wed, Jul 31, 2002 at 03:06:02PM -0500, Christopher Cramer wrote:
> > I have no idea why you think it would better, but with certain types of
> > applications, it's impossible.
> > 
> > For sake of argument, let's say there are two different ways to use Guile.
> > One way is to extend Guile through C, by using load-extension. This works
> > fine if the C code is ignorant of the module system (writing a wrapper
> > module in Scheme handles everything). The other way is to extend C through
> > Guile, which cannot stay module system ignorant, because you typically
> > want to load multiple Scheme scripts without worrying about clashing
> > symbols from the different scripts -- this is currently impossible
> > without getting deep into the details of the module system.
> 
> Yes, this is exactly the situation i just encountered. I know that
> everyone and their grandmother tells me to write everything in the
> scripting language but i just don't feel like rewriting Apache in guile --
> besides: that might p**s of a lot of perl hackers ;-)

I think just makes sense to write as much of your system in the
extension language as possible, once you have an extension language.
If you'd rather write it in C..., well, I guess we have to just accept
that.

>  - save execution/evaluation of script code. I need to ensure that i
>    can reliably dissable certain things: a user script should not be
>    allowed to call (exit 0) and bring down the whole webserver ;-)

However, you should be careful not to accidentally reimplement the
OS's security features in your application.  The fewer code you have
to trust the better.  I don't want to trust Java to keep its sandboxes
clean.  I'd rather factor the application into a number of processes
that run in a chroot jail with their own uid/gid and have the
kernel/hardware watch them.  Untrusted external code would be run
inside such a restricted process.

>  - An (opaque) representation of an 'interpreter'. One thing i found 
>    rather elegant in TCL (perl to, if i recall correctly) was the
>    possiblility to run several interpreters in parallel. Guile seems
>    to completly lack this (i think i understand why, but i still miss
>    it).

What is an 'interpreter'?  What do multiple instances of the
interpreter have in common, what is specific to each instance?  I
think that once you know what you want from multiple interpreters, you
can implement them easily with the features we already have.  Or with
fork.

>  - Thread support.

Yep, but it seems to be hard in its full generality.  Cooperative
threads work fine, tho.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel