Re: About coroutines and light threads

[Edgar Toernig <froese@...>]

Sebby wrote:
>
> Edgar wrote:
> 
> > Lua has to be changed.  Each coroutine needs a local C _and_ Lua
> > stack.
> > So, you do not have one Lua stack but as many as you have
> > coroutines.
> > And these additional stacks have to be taken care off by the garbage
> > collector.  (And, coroutines should be garbage collected, too.)
> 
> 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.

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

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

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

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

Ciao, ET.

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