Re: [Sbcl-devel] Patch for review: *default-special-bindings* for
new threads

Gábor Melis <mega@...> writes:
> Such a simple thing. But when it leads to thread safety issues it can
> become quite tricksome.
Quite. ;-)
I was writing an example about how your way was bad, when I finally
saw the light. You are rigth and I was wrong.
The example that made me see it:
Thread T is a worker thread, executing arbitrary code injected to the
system from a trusted source. When T starts, package FOO has not been
loaded yet. FOO:*BAR* is a thread-local special -- or at least should
be. After FOO has been loaded, T will execute code that frobs
FOO:*BAR* with impunity.
I believe this models your canonical case?
If MAKE-SYMBOL-THREAD-LOCAL make FOO:*BAR* local in already running T,
then all is fine and dandy, I guess. I'm happy with your model in
this case.
If MAKE-SYMBOL-THREAD-LOCAL works via just *DEFAULT-BINDINGS* or
similar, then code like this simply cannot work. This may or may not
be a show-stopper, I don't know. What happens if someone unwittingly
tries to make it work? If there are there are multiple worker threads
running when FOO is loaded, then they will mess each other up. Nasty.
I think your earlier position about global bindings was on the right
track, though:
Code used in running threads assumes *FOO* is either thread-local or
global (the example works the same either way), and frobs it with
impunity.
In reality, *FOO* is indeed supposed to be just so (or just the
opposite, the example still works!), but due to the way threads have
been started interleaved with the loading of the code, T has been
started at a point when *FOO* was special, but not yet thread-local.
In this case the code (build-system, whatever) is obviously buggy, and
some lossage is going to happen no matter what we do:
If executing MAKE-SYMBOL-THREAD-LOCAL or equivalent causes *FOO* to
get its own binding in T, then the system is going to behave one way
(correct or wrong) till that point, and just the opposite from then
on.
This sounds like a horribly nasty to track down, especially if *FOO*
is supposed to be local -- something corrupts the system, but when
you inspect the it *FOO* is local in each thread!
I would say that to keep things sane you should not be allowed to
proclaim a variable thread-local if it is already special.
Cheers, (feeling slightly like a weathervane)
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."