[e-lang] Q: asynchronous tail recursion?
Constantine Plotnikov
constantine.plotnikov at gmail.com
Fri Dec 29 06:21:21 CST 2006
On 12/28/06, Kevin Reid <kpreid at mac.com> wrote:
> In the multiple-vat case, this same algorithm should work given that
> support for inter-vat weak references is provided, which seems doable
> (with one extra reference table pair added to CapTP and the weak ref
> system being aware of far refs).
>
I think that this problem is at least non-trivial. A complete and
exact DCG is challenging task already. Weak references will add new
complication to already too complex problem.
I see a big challenge for distributed weak reference detection for
implementation that is based on unmodified Java runtime. A weak
reference is notified (using queue) that it has been cleared because
it become weakly reachable rather than about the fact it is about to
be cleared (http://java.sun.com/javase/6/docs/api/java/lang/ref/WeakReference.html).
Lets consider situation when A, B, C are located in different vats on
different JVMs.
The question is weather CapTP should refer to B using strong or weak reference.
If CapTP instance associated with B's Vat is referring to B using
strong reference, it is unable to detect that B is no more referenced
from vat B. If CapTP is referring to B using weak reference, than it
will loose instance as soon as it become unreferenced from local vat
however it could be still referenced from remote vats.
So support for distributed weak references will likely require at
least modification modification of the runtime to introduce new
reference type (AlmostWeakReference?). And even in this case, I'm not
sure that problem is solvable in practice.
This is why I'm suggesting that to implement tail recursion support in
the compiler rather than in the library. The compiler is capable to
see promise usage and to eliminate extra indirection levels where it
is safe to do. As additional bonus, there will be less promises
created, so it should speed up the language a bit without changing
semantics.
Constantine
More information about the e-lang
mailing list