On Wednesday 09 August 2006 11:11, Nikodemus Siivola wrote:
> 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?
Yes, this is what I tried to articulate.
> 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 don't quite get what you say here. Is it that without giving already
running threads separate bindings the example above cannot work?
> 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
> 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
This kind of lossage seemed to me to follow from the general
transactionlessness of lisp. There are all kinds of problems with half
loaded code having logical dependency on the yet unloaded part.
/me waves generously in the general direction of the audience
> 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.
I suggested to Max emitting a warning if there is global binding for the
special at the time of its thread-localization. That was a somewhat
half baked attempt at mimimizing surprises. This is probably better.
> Cheers, (feeling slightly like a weathervane)
> -- Nikodemus Schemer: "Buddha is small, clean, and
> serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."