This is the mail archive of the
mailing list for the guile project.
Re: c++ -> guile threading
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
This is sort of a large, drooling security hole.
> So far so good, but the problem is, what if someone uploads a bit of
> infinitly recursive code? If the server is single threaded, then the
> whole thing grinds to a halt.
> So my thought is, what if I were to write the server multithreaded, and
> start an new thread for each new user? Scheme code for a user is executed
> in his/her own thread, so if they screw up they don't affect other people.
> What I would *like* to do is, from my C++ code, create a new thread and be
> able to arbitrarily move between guile and C++ (guile calling C functions,
> C running guile on various expressions) in that thread, whilst other
> threads are ALSO using guile for stuff.
> >From what I've been able to gather, if I recompile guile with
> --enable-threads, then I can use QuickThreads in guile. Does this mean I
> can start quickthread threads in C++ and guile will reconignize them as
> such? However, QT are app-level instead of OS-level threads... I'm on an
> SMP system and would much prefer OS-level threads (i.e. pthreads). What
> is the status on pthreads? The current stable release (1.3) has some code
> hanging around for mit-pthreads but from what I can tell it doesn't
> work... At any rate you can't easily enable it in the makefile.
OS level threads aren't currently supported. There has been some work
(there's an initial pthreads patch, linked from the projects list at
but there are still issues that need to be resolved in guile to make
it play nice with os threads).
> The other option would be to write a single-threaded app and somehow limit
> the amount of time that a user's code can spend in the guile system, but I
> don't know how I would go about interrupting and canceling execution like
> so... Perhaps setting and alarm and catching the signal, but is there a
> scm_??? function that cause guile to drop everything and return that would
> be callable from a signal handler?
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).