This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
Re: multiple top-level environments (one per ServletContext)
- To: brlewis at alum dot mit dot edu
- Subject: Re: multiple top-level environments (one per ServletContext)
- From: Per Bothner <per at bothner dot com>
- Date: 28 Mar 2001 20:21:20 -0800
- Cc: kawa at sources dot redhat dot com
- References: <E14huyk-0005AM-00@softdev>
brlewis@alum.mit.edu writes:
> >First, you may not realize that using separate top-level environments
> >requires using separate threads - and specifically Futures. Rather,
> >you can have as many environments as you like - but the "current"
> >environment is found by Environment.getCurrent(), which checks if the
> >current thread is a Future.
>
> This is the way it will continue to be? Code to use Futures
> won't become unnecessary at some point?
Well, we need some way to find the "current" top-level environment.
You don't want to do that globally, which leaves two alternatives:
(1) per-thread, which means having sme kind of thread-to-Environment
mapping.
(2) per-(call-)frame - i.e. pass the current top-level environment
as an implicit parameter.
The current approach is (1). It can be generalized to arbitrary Threads,
not just sub-classes of Future, presumably by using some kind of hash
table. There are performance costs to this, plus there may be some
resorce reclaimation issues (you want to remove the thread entry from
the table when the tread dies). Using an interface instead of Future
may be reasonable, but it doesn't change the general idea.
I am slowly trying to work out a new calling convention where
procedures are mapped to methods that just take a single CallContext
(see gnu.mapping) argument. The goal is to handle full tail-calls,
call/cc, and generic functions relatively efficiently. In that case,
a CallContext could include a pointer to the top-level Environment
to use; this would be a variant of (2).
I haven't decided on whether this new calling convention (if/when
it is implemented) will be the default calling convention. It
probably won't be the only one. I don't know whether it would
make most sense for BRL. I guess we'll have to see how it works
out.
> >Secondly, there are a number of knowm problems with the implementation
> >of environments. I think fixing these problems is very urgent. I
> >don't know for sure which one specifically is biting you.
>
> Are some of these fixed in the CVS version?
Quite possibly, but I don't don't remember what I was specifically
referring to. I know I've changed and fixed various things relative
to environments. I also know I have more things to do, including a
bunch of changes not yet checked in.
--
--Per Bothner
per@bothner.com http://www.bothner.com/~per/