Re: About coroutines and light threads

[Edgar Toernig <froese@...>]

Sebby wrote:
> 
> Ok, the lua_State has 2 seperate sections (it's even noted in the
> source code). One section is the global environement, the other is
> thread specific. Even though i havn't tested this throughly, what i
> do is create thoes sections seperately. I create one global
> environement and one thread environement per thread. Then before
> executing a thread i bind them together to get a complete lua_State.
> If this is really a valid way of doing it but it seems like it works
> from my tests (maybe lhf, can confirm this).
> 
> Edgar wrote:
> >
> > But the gc has to see _all_ data when he starts.  Else you get
> > memory corruption.
> 
> Well, the gc is part of the global environement. And each thread is
> bound at runtime to it. So unless you terminate a thread
> prematureley, that should be a problem.

And here's your problem.  The Lua stack of inactive threads has
references to objects.  But the gc has no knowledge of these
inactive threads and will not mark the objects referenced by their
stacks.  So the objects will be freed.  And when a thread later
becomes active he has references to freed objects.  Boom.

> > And, if not you better start modifying your C compiler to support
> fragmented stacks *ig*
> 
> I'd be
> nice to have some way to allocate a default stack and get it to grow
> when needed. I guess i'd be doable on some platforms if you could
> intercept stack overflows.

It can be done by the C compiler.  It has to generate enter/leave
function stubs with information about how many bytes are needed
by this function.  Iirc the SAS C compiler for the Amiga did this.

Ciao, ET.