[imp-hackers] problems with *DEFAULT-SPECIAL-BINDINGS*

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Sat Apr 3 14:00:40 UTC 2010


On Sat, Apr 3, 2010 at 1:01 PM, Tobias C. Rittweiler <tcr at freebits.de>wrote:

> Let's say your Lisp development environment is multi-threaded and allows
> you to run multiple listeners at the same time. Each listener is run in
> its own thread.
>  Now, you opened a few listeners, then loaded in this library which
> pushes onto *DEFAULT-SPECIAL-BINDINGS*. Now all running listeners, when
> the user uses them to call into that library, will operate on the _same_
> global binding.


Depending on the way special variable bindings are implemented, this could
be easily achieved, but only with changes in the implementation.

One situation where this could not be done is when the implementation uses
PROGV to create thread-local assignments. Typically each thread corresponds
to a lambda form which is executed in a fresh new lexical environment and
thus lambda form uses PROGV and the list of thread-local variables to
establish those bindings. In this case I see no way to change the set of
local assignments without a complicated manipulation of the binding stack,
which might not be possible at all.

Other implementations like ECL use a hash table to implement special
variable bindings. This  is the place where LET/LET* store the local
bindings to a special variable and for this reason this table is looked up
before anything else. Inserting a value into this table causes all bindings
of the variable to be thread local. However this can only be done if there
was no previous binding. In other words: we can make all new bindings
thread-local but we can not turn a variable from global to thread-local if
this variable already appears in a LET/LET* form.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/implementation-hackers/attachments/20100403/6ed05365/attachment.html>


More information about the implementation-hackers mailing list