This is the mail archive of the kawa@sources.redhat.com mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Gargage collected top-level bindings?


Do you really need a mechanism for "relating" threads that want to
share (i.e. inherit from) a global Environment?  Why not just assume
that "global" means "shared by all threads", and it's up to the
programmer to figure out how to use it effectively?

It seems to me that the "global" environment should be exactly that:
global.  It would serve the same function as Java's package/class
namespace.  You'd use it for sharing the absolute top-level
functionality in a non-distributed (i.e. single OS process) program.  
I see no reason the Kawa global environment couldn't be shared by all
threads, independent of whether it's considered a static or dynamic
environment.  It's just the top-level, the default, whatever you get
when no static or dynamic lookup succeeds.

I see no need to provide an "escape" for threads that don't want to
share the global environment.  Or at least I don't see a reason to let
it stop you from adding the global environment in the first place.
You can always add in those controls later, if they're needed.

At the moment, Java provides a global namespace via its class
namespace.  This provides programmers with a convenient mechanism
for top-level program organization.  You can invoke any number of
Singleton or Factory methods to get at core, shared functionality.
With Kawa, in its latest incarnation, you have to have your startup
thread initialize a bunch of stuff, then pass references to helper
threads as parameters.  There's no way to "decouple" your program
components by using a lightweight global namespace as a shared
directory.  And certainly there's no convenient way to pass your
global state information to built-in Java threads (e.g. the Swing
thread). <p>

Is there a reason "global" shouldn't mean "default" across all threads,
regardless of whether they're Java threads or Kawa futures?  The problem,
as I see it, is that it would be difficult to define inheritance relationships
among threads over which you have no control -- particularly JVM threads
that you need to interact with.

-steve


On 5/9/05, Per Bothner <per@bothner.com> wrote:
> 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/
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]