From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: scm_* API extension? [was] scm_* API question Date: 05 Aug 2002 19:51:11 +0200 Sender: guile-devel-admin@gnu.org Message-ID: References: <20020730121436.GA4465@www> <20020730200929.A18106@kiwi.pyrotechnics.com> <20020731100300.GC5661@www> <20020731150602.A32555@kiwi.pyrotechnics.com> <20020801094121.GC7425@www> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1028569891 22628 127.0.0.1 (5 Aug 2002 17:51:31 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 5 Aug 2002 17:51:31 +0000 (UTC) Cc: guile-devel@gnu.org Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17bm0w-0005sr-00 for ; Mon, 05 Aug 2002 19:51:30 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17bm1Y-0006AX-00; Mon, 05 Aug 2002 13:52:08 -0400 Original-Received: from krusty.dt.e-technik.uni-dortmund.de ([129.217.163.1] helo=mail.dt.e-technik.uni-dortmund.de) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17bm1L-00069X-00 for ; Mon, 05 Aug 2002 13:51:55 -0400 Original-Received: from burns.dt.e-technik.uni-dortmund.de (burns.dt.e-technik.uni-dortmund.de [129.217.163.19]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id B9CD2A3831; Mon, 5 Aug 2002 19:51:53 +0200 (CEST) Original-Received: by burns.dt.e-technik.uni-dortmund.de (Postfix, from userid 520) id 91E152613A; Mon, 5 Aug 2002 19:51:11 +0200 (CEST) Original-To: rm@fabula.de In-Reply-To: <20020801094121.GC7425@www> Original-Lines: 53 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:987 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:987 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