lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Tue, Sep 09, 1997 at 08:21:07PM -0300, Mark Ian Barlow wrote:
> In message <199709091844.PAA08845@server02> 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.


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