> I think the problem is that threads are a very low-level, troublesome
i don't think they have to be. it's just that the default primitives
provided make it very difficult to write threaded programs that
are easy to reason about. it was that very problem that led me
into this arena, and in response to which i wrote a package
that provides a somewhat nicer primitive  (BTW, i'd love
to know if it works under platforms other than SBCL).
> If you want to
> interact with Tk from multiple threads, you'll need to instead
> communicate with the main GUI thread, and have it do the talking.
> That would be easier if you used :serve-event t in with-ltk, and if
> you could arrange for a serve-event handler to run only in one thread.
the serve-event argument to with-ltk is undocumented.
i did notice it when i glanced at the code, but it wasn't clear to me how it
was meant to be used, or whether it was a supported feature.
ltk was just an example, but in fact, from a quick read through the
source, it looks as if it was in fact pretty much thread-safe the way that
i was using it (the main query is what happens if one accesses a hash
table at the same time as another thread is adding to it - the sbcl version
seems to be protected by a spin lock, which would seem to make it ok).