On 2018-11-22 12:10, Donal K. Fellows wrote:
> I'm trying to figure out why you're going to all this work, since you
> could instead just run a Tcl interpreter in a real thread of its own.
In case of real thread I need to support all kind of magical
synchronization between threads. Green threads does some interesting suff:
a) no syncing needed via OS thread primitives
b) possibility to suspend execution at will
c) possibility to create debugger in embedded application
d) serialize internal stack(s) some day for real suspend (yes, fairly
tales but still possible)
> But apart from that basic question, you have a separate problem that the
> granularity level that you're injecting at isn't designed for what
> you're trying to do. The NR callbacks you're (ab)using aren't at all a
> one-to-one match with commands; a command may generate no callbacks at
> all (e.g., if it is compiled to bytecode that's pretty likely) or it may
> use multiple callbacks, and those won't be always obvious ones from an
> external perspective.
I'm aware of that. Actually I did some testing of this code and it seems
to be perfectly okay with granularity level. This is what I expect.
> (For example, TclOO uses several stacked callbacks
> to handle call data-structure memory management.) Also, the callbacks
> are managed in a stack (but not the C stack); if you're adding your own
> callbacks
I'm not adding my own callbacks for now. Just using what came with TCL.
>, they might not get called for a while (and some operations
> such as traces or scripted-IO callbacks run in ways that *really*
> shouldn't be suspended; the C stack will actually contain real stack
> frames while they're running because we can't wrap our heads around
> fixing them).
That is perfectly okay. I do understand all problems with green threads
/ coroutines. It does not makes them less interesting to me since this
is proper solution in my case. I have no way to explain this in details
since my code is closed source. Believe however that I do understand
what I'm trying to accomplish.
> You _might_ get better behaviour if you also install an interpreter
> command stepping trace
*Slow*. Already using this. Also, this does not *returns* to me at all
with is a point in this discussion. I'm just getting some kind of
callback with unknown C-stack and only option I have is to use
boost::context continuations to run away from this. Both tracing and
boost::context are slow. This is *NOT* an option for single-step solution.
Doing single step seems to be fast and proper way to handle full return
from C-stack as frequent as possible.
Actually whole point of this is this ridiculous loop inside
TclNRRunCallbacks. I do not need this, but there is no way around it
[1]. It would be interesting to have TclNRRunSingleCallback instead.
This would solve many problems with really using TCl as
coroutine/continuation from C code. Yes, just this small change would be
sufficient. TclNRRunCallbacks can be where it is for rest of 99.9% cases.
[1] I did some research over the years and this loop can be found in
many different language engines I've tried. Surprising, since many of
them can be converted to continuations by *removing* this useless loop
just like that without loosing any features. I still do not understand
why this loop is so important for everyone that is came for free with
soooo many languages ... :).