Next Previous Contents

9. And now what? Still lots to do ...

Things that need more work

9.1 Script level functionality

What, how should be accessible from scripts?

9.2 How many stacks?

Remark that we call them stacks independently of their implementation: the CallFrame and EvalFrame stacks are actually linked lists, the evaluation stack is a contiguous region of memory.

Current Tcl

Why are the CallFrame stack and the evaluation stack defined on a per interp basis?

The execution flow nests perfectly on a per thread basis (per muThread in NRE), maybe there is an issue on interp deletion? If they could be unified ...

The evaluation stack should maybe become "one per thread" . This relies on the fact that Tcl bytecodes are always stack neutral - on return, they leave the stack at the same position they found it. This should improve the memory efficiency of Tcl.

NRE

We are now at:

Is this optimal? Costs & benefits of unifying?

My first impression is: one EvalFrame per muThread and one CallFrame per interp are harmless at worst; I do not immediately see a reason to unify them. The evaluation stack should maybe become " one per muThread" (see above).

There *may* be an issue with async calls in the same interp, if and when async is " a different thread of execution in the same interp" !

9.3 The Tcl event loop

Should it be part of this framework?

9.4 New Tcl_Obj types?

Should we define new Tcl_Obj types for EvalFrame, muThread or other structures? I guess it will depend on the desired script level functionality.

9.5 What is still missing

Programming tools and API

Stacklessness and debuggers

In order to debug the code, it is sometimes useful to make it run in stackful mode - otherwise, all the info in the C backtrace is (obviously and purposefuly) gone.

9.6 Docs, more docs ...

I'm sure this stuff will need better explanations, forever and ever.

9.7 Other engine modifications

Orthogonal possibilities:


Next Previous Contents