Tcl adept wanted for Stackless problem

[Jean-Claude Wippler]

Christian Tismer <tismer at tismer.com> wrote:

> My big question is:
> When does Tcl use C stack entries as globals, which
> are passed as function arguments to interpreter calls?
> This is of special interest when Python callbacks
> are invoked.
> The problem is, that I use stack slicing, which moves
> parts of the C stack away at some times, and I need
> to know when I am forbidden to do that. It is solved
> to some extent, but not all.

This may be caused by a CallFrame struct allocated on the stack in 
tclObjInterpProc (file generic/tclProc.c).  Am following up by email, 
have also CC'd Miguel Sofer on that email discussion.  The solution to 
this particular issue is within reach, IMO.

The point is that Tcl can access dynamic scope through its upvar and 
uplevel commands, but AFAICT only that CallFrame struct chain has any 
problems with the (terrific) stack-switching tricks you're playing.

> That's unfortunately not all.
> A friend is running the Tcl/Tk mainloop in one real thread,
> and stackless tasklets are running in another one (of course
> calling into Tcl). When tasklet switches are performed
> (again, this is moving stack contents around), there appear
> to be crashes, too.
> This kind of slicing should be allowed IMHO, since these
> are different contexts, which shouldn't interact at all.
> Are there any structures which are shared between threads
> that use Tcl/Tk? Something that may not disappear during
> some operations?

Evidently, Tcl better be compiled with thread support.  If it is, then 
that ought to do it.  Tcl threads run in parallel, with all shared data 
protected by mutexes.  Ought to be quite stable, given that AOLserver 
can use an unmodified threaded Tcl nowadays.

Not sure, perhaps it's the same issue...

One thought: Tcl 8.4b1 is due out any day now, might be a good way to 
make sure you're not hitting some recently resolved snag.

-jcw