Re: About coroutines and light threads

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

Hello.

> > Ok. Well as for having a different stack per lua thread, it's
> > possible without actualy modifying lua. I have basicly wrote an 
API
> > that sits on top of lua and takes care of different tasks. For
> > example, it will create lua_states for different threads, and will
> > even bind the global section with the thread specific section when
> > comes the time of execution.
> 
> ???  I want threads/coroutines to share data with each other.  I 
don't
> understand how you'll do this with different lua_states.

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

> > The only hack required
> > for this is copy/pasting the code from lua_open to create your own
> > thread specific states.
> 
> 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.

> > Hmm. I wonder how standard sigaltstack is. I'll have to look it 
up in
> > visual studio tonight. If it's standard then it should be 
possible to
> > write a completeley platform independant solution.
> 
> Someone already tried it.  He even had to put #ifdefs in it to only
> let it run on BSD and Linux.  So much about portable *g*

Doesn't surprise me :)

> 
> > Well on a PC running windows, you cannot simply assume you have
> > plenty of memory allocated for a stack and simply allocate it on
> > demand. However there is way to reserve chuncks of memory via the 
OS.
> 
> OS?  What OS?  *eg*

Windows, you could probably do a GlobalAlloc to reserve some memory 
for the stack.

> > The problem is that on other plateforms like Playstation2 which 
only
> > has 16MB of memory, the allocation has to be considered carefully
> > since you'd want to use the most of that memory for actual
> > geometry/textures rather than thread stacks.
> 
> That's right.  But on these systems you normally have very detailed
> knowledge about stack usage of your routines.  And, if not you 
better
> start modifying your C compiler to support fragmented stacks *ig*

Yes. But then it implies who ever starts threads must have some 
priori knowledge of the stack space this thread would need. 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.

> (Btw, 16MB?  32MB!  Or are they cheating again?)

Eh, i thought it was 16MB. May be wrong. Hey, i got one of thoes 
expensive PS2 Dev Boxes on my dest and i havn't even used it :P

Sebastien St-Laurent
Software engineer, Z-Axis ltd
sebby@z-axis.com