[armedbear-devel] ABCL threading questions
evenson at panix.com
Wed Aug 3 13:25:56 UTC 2011
On Aug 3, 2011, at 15:02 , David Wang wrote:
> I just started working with ABCL's (version 0.26.1) threading
> functionality and had two questions along those lines:
> 1. Is there documentation for the threading support somewhere? Even a
> list of applicable methods and which src files they are defined in
> would be useful. I already found threads.lisp and abcl's swank
> interface. I was wondering if there were conditional-variables or
> conditional-waits, and was just interested in seeing what other
> functionality is currently supported.
Unfortunately, there isn't much documentation from ABCL on threading.
In fact there isn't much documentation at all as we're just starting
to work on a manual for our implementation.
But I might advise studying the [Bordeaux Threads (BT) implementation
of conditional variables that I recently contributed] (unfortunately
this hasn't been released so you need to get the latest version
from the git repository). Essentially what is going on in this
code is a translation of various constructs defined in the JVM
concurrent APIs to the Lisp abstractions provided by BT. POSIX-style
condition variables are part of the BT API.
Additionally, [Chuan Bian spent some work on getting Portable-threads
working with ABCL] based on my work with Bordeaux Threads which
might offer further opportunity for enlightenment.
> 2. This question is a little more complicated, and deals with when
> (format t "text") will print to std-out/repl and when it won't.
> When I make a thread that uses (format t ...), I can see the output on
> the std-out/repl when I run abcl from a terminal, but not when I run
> it from emacs/slime. I'm guessing the reason for this is that swank
> doesn't redirect output from the other threads to emacs.
> a.) Is there a reason for not redirecting this output? i.e. will it
> interfere with swank's operation?
> b.) Is there a fix or some places I should look to see if I can write a fix?
I believe that the input is showing up in the associated *inferior-lisp*
buffer. As far as I understand things this results from the use
of dynamic bindings for the streams for REPL commands in the SLIME
architecture which essentially means that the SLIME REPL buffer is
not conceptually the same as *STANDARD-OUTPUT* for execution not
happening in response to a REPL input.
See the [documentation for SWANK:*GLOBALLY-REDIRECT-IO*] which
you probably want to set to T to get the behavior you expect.
"A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
More information about the armedbear-devel