This is the mail archive of the
mailing list for the Guile project.
Re: c++ -> guile threading
Peter Amstutz <email@example.com> writes:
> On Fri, 7 May 1999, Greg Harvey wrote:
> > Peter Amstutz <firstname.lastname@example.org> writes:
> > > The server part of this apps is going to serve many users at once. Users
> > > will be able to upload bits of their own scheme to automate server
> > > tasks.
> > This is sort of a large, drooling security hole.
> This brings up a seperate question then: how do I start up a "blank"
> guile system - one with a nearly bare environment that's just keywords
> (define, let, if, lambda, etc...) so I can just allow in library calls
> (both my own and some standard scheme) deemed to be safe?
What you could do, is run the user code in a module that redefines all
the stuff that you don't want them to access. It's currently not the
nicest solution; I think this is something that should be looked at
once the environment stuff is implemented (and just in case I'm
correctly anticipating your next question, I have no idea when that'll
be ;) Jost Boekemeier has done some work on this, but I haven't had
the time to sit down with his code yet). You could also scan through
their code to make sure they aren't using anything funky, but that's
probably a bit too dangerous, since you could always miss something.
> > OS level threads aren't currently supported. There has been some work
> > (there's an initial pthreads patch, linked from the projects list at
> > http://home.thezone.net/~gharvey/guile/guile-projects.html
> > but there are still issues that need to be resolved in guile to make
> > it play nice with os threads).
> Uh, sounds messy...
Yeah, there's definately not anything close to ready for prime time
with os threads yet.
> What I am considering now is threading just the C,
> and putting the guile system in one thread and having a queue of "scheme
> requests"... Basically batch processing scripting stuff in a single
> thread but still in-processes so to have easy access to data structures.
> It seems most doable at the moment.
> > You should be able to do this with asyncs (see async.c in the libguile
> > directory). The source file contains some documentation on how to use
> > them, and instructions on how to use them from unix signal handlers (I
> > have partial written documentation on this, but there are a few bits I
> > still need to figure out, so it's not available yet).
> It's pretty vague... A bit of example code showing what/how this
> works would be quite enlightening :)
Wouldn't it, tho? ;) Thinking a bit more about it (like, about how
much I should've thought first), it's probably just as well to use
guile's own threads (or go with your idea), since you'd essentially be
reimplementing threads this way (I wasn't thinking about resuming the
user code when I wrote that... it's easy if you just chuck it after
their time is up >;'), but that probably wouldn't be a really great