[Bug-kawa] Re: [bug #14072] inconsistent binding behavior for threads

[thomas kirk]

Thanks, I suspected that this might be the case, which is why I was 
unsure about calling it a bug myself. The confounding thing was the
inconsistent behavior, i.e. the fact that the code didn't fail outright
in every case. I'll follow up with an RFE.

I can't think of a reason to use Threads the way my test cases did,
but I frequently want to pass scheme functions to java code that
expects a Runnable. Perhaps an appropriate way to handle this is a Kawa 
implementation of Runnable that mirrors the implementation of Future.

In fact, a quick&dirty Kawa class implementing Runnable appears to have 
exactly the behavior I'm looking for. 


 > I don't think this is a bug.
 > The issue is how a thread inherits the evironment from a parent thread.  This
 > is only supported when creating a Future.  Generalizing Environment
 > inheritance for arbitrary threads is difficult.  The problem is how do you
 > get the Environment of a parent thread?  Currently we use a ThreadLocal to
 > map from the current thread to its CallContext and hence to its Environment,
 > but you cannot get the ThreadLocal binding for any other thread.
 > It may be possible to use a a HashTable or similar to map a Thread to its
 > Environment, and thus get the parent thread's Environment, but garbage
 > collection makes this difficult.  (Using a WeakHashMap is an option, but only
 > correct the Environemnt when the Thread is collected; not when the thread
 > finishes.)
 > An API to allow the programmer to explicitly request that a child thread
 > inherit it's parents Environment is desirable; you could submit a new "bug"
 > as an enhancement request?