Re: multiple interpreters x multiple threads x multiple environments

[David Jeske <jeske@...>]

On Tue, Sep 09, 1997 at 08:21:07PM -0300, Mark Ian Barlow wrote:
> In message <199709091844.PAA08845@server02> lua-l@tecgraf.puc-rio.br writes:
>  > About the on-going discussion on multiple threads:
>  > 
>  > Like Roberto said, multiple threads of execution in Lua would require
>  > support on the C part, something that neither ANSI C nor POSIX can give.
> 
> Agreed.

Agreed.

>  > Now, it seems to me that when people talk about multiple threads they mean
>  > multiple interpreters, as in Tcl.
> 
> Not the games folk; I think they want a multitasking mini OS-let.

Actually, I don't want Lua to know anything about multitasking. I just
want to be able to "really" instantiate multiple (completely independent)
interpreters. I'll deal with the multithreading issues at a higher-level
and completely separate from Lua. 

Perhaps it would make more sense to just completely remove any "issues" of
multithreading from this discussion. However, because I want to use it in
this manner, the setglobal/getglobal or tag method stuff won't do what I
want. I really just want all global lua state to be instantiatable inside
a global state structure, and that's it, someone might want to wrap a C++
class around this and make a "Lua-Interpreter" class.

> Now this is *very* interesting, and potentially pretty efficient if we used
> C for the tag methods. If we volountarily restrict ourselves to NOT calling
> any C functions that subsequently call Lua, so that C function calls can be
> treated as atomic, we could use the debug interface to build a preemptive
> multi-tasker. (I don't think that restriction would bother too may users.)

I looked at using the debug interface for doing "in-lua threads" however I
didn't think it allowed me to create and switch between separate Lua
stacks, which is what I would want to do to create threading within lua.

-- 
David Jeske (N9LCA) + jeske@chat.net