Re: Gargage collected top-level bindings?

[Per Bothner <per at bothner dot com>]

Dean Ferreyra wrote:
> I CVS updated this morning.  There is one problem I've run into that is 
> still leading to UnboundLocationExceptions in our code around the use of 
> define-variable.
>
> I can see it in my test case, too---just define VAR with 
> "define-variable" like so:

I don't think this is a bug.
'define-variable VAR' means "lookup VAR dynamically" - i.e. in the
per-thread dynamic environment.
Since the module is static, there is only a single "instance", and
top-level actions are only performed once.  That creates bindings
in one thread.
Since the two threads aren't in an inheritance relationship, the second
thread won't and shouldn't see the definition in the first thread.

It may be possible to change define-variable so it sets the "default"
binding of VAR, rather than the current thread's.  But I don't think
that would be right.  The difference with (define VAR ...) is that it
declares a static binding, while define-variable explicitly says to
use dynamic lookup.  Thus (define VAR ...) creates an anonymous
ThreadLocation for VAR, in that just (eval 'VAR) won't find it.

So:
  (define VAR xx)
  ... VAR ...
gets translated to:
  static public final VAR = new ThreadLocation();
  static { VAR.set(xx); }
  ...VAR.get()...

If we do:
  (define-variable VAR xx)
  ... VAR ...
then the latter is equivalent to:
  (eval 'VAR)
though we do cache a ThreadLocation for performance.
I don't think an *unrelated* thread should be able to do (eval 'VAR).

Note I wrote "unrelated" thread.  It might be useful to add a mechanism
so "related" threads could inherit from a shared Environment.  But where
do we draw the line: how do we control it so that some but not all
threads share a "global" Environment?  Make use of ThreadGroups?
Make use of ClassLoaders?
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/