[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Difficult Problem
From: |
Rob Browning |
Subject: |
Re: Difficult Problem |
Date: |
Wed, 29 Aug 2001 22:23:31 -0500 |
User-agent: |
Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 |
"Crowder, Brian" <address@hidden> writes:
> Okay, well... I was able to make this work by kludging in some goo
> in the thread spawn for the one thread which will run guile.... I'd
> still optimally rather have multiple guile-threads, but that's fine
> for now. :) It turns out, it needn't be the main thread. You can
> run gh_enter() from any thread, as long as it happens earlier in the
> stack than any other guile goodness.
As it stands now, Guile doesn't know anything about multiple kernel
(i.e. POSIX) threads in an app. However, it *might* be possible to
run multiple guile threads from within the guile interpreter running
on one of your kernel threads.
Of course dealing with the headache of having to manage multiple
kernel threads *and* multiple guile threads inside one of those kernel
threads is another issue entirely :>
Also, if you have a semi-repeating (or at least not totally random)
set of work that you want done on the guile side, you might be able to
get a bit more efficiency by creating thunks to do the job(s) and
storing the resulting SCM's in globals (or somewhere that your kernel
threads can get at them), and then push those when appropriate, rather
than strings that have to be read/evaled, onto the guile thread's work
queue. However there might be some tricky timing issues there. You
have to be able to safely synchronize the other kernel threads
activities with the guile interpreter thread. Of course that's true
no matter what solution you choose.
Hope this helps.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD