Re: About coroutines and light threads

["Sebby " <beast@...>]

> > > 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.

Okay, then the question is how does the Lua GC work? Ok, i'v heard it 
isn't by refcount, but how does it keep track of used/unused objects. 
Maybe if i knew this, i could avoid this situation. Cuz then again, 
wether or not i use coroutines, it doesn't matter, i'll have this 
problem if i don't create a global state per thread, which is exactly 
what i want to avoid.

> 
> > > 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.

Ok, but that could be done on a Lua->C context where you can examine 
the function you're calling. But in cases of C->C calls, you can't do 
much. Unless you can get the compiler to write out custom stubs so 
you can track stack usage per function.

Sebastien St-Laurent