multiple interpreters x multiple threads x multiple environments

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

multiple interpreters x multiple threads x multiple environments

Luiz Henrique de Figueiredo-2
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.

Now, it seems to me that when people talk about multiple threads they mean
multiple interpreters, as in Tcl.
Lua does not support multiple interpreters, but it does provide ways to
implement multiple environments.
By multiple environments I mean multiple global environments, so that a
variable can have the same name in two environments, but different values,
or exist only in one environment, etc.

Multiple environments are easy to implement in Lua.
One way is as Roberto mentioned: use tables to save and restore the global
environment.
Another way is to use the setglobal/getglobal tag methods.
In this solution, these tag methods are used to filter and redirect requests
to read and write the global environment, say to tables.
To switch environments, simply change the handlers for setglobal/getglobal.

Maybe this should be in the FAQ (which is in desperate need of updating).
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: multiple interpreters x multiple threads x multiple environments

Mark Ian Barlow
In message <199709091844.PAA08845@server02> [hidden email] 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.

 > Lua does not support multiple interpreters, but it does provide ways to
 > implement multiple environments.
 > By multiple environments I mean multiple global environments, so that a
 > variable can have the same name in two environments, but different values,
 > or exist only in one environment, etc.
 > 
 > Multiple environments are easy to implement in Lua.
 > One way is as Roberto mentioned: use tables to save and restore the global
 > environment.

This is surely incredibly slow?

 > Another way is to use the setglobal/getglobal tag methods.
 > In this solution, these tag methods are used to filter and redirect requests
 > to read and write the global environment, say to tables.
 > To switch environments, simply change the handlers for setglobal/getglobal.


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


To do this we would need a means of swapping the VM's instruction
pointer when a context switch was required. (we would of course swap the
global environment pointer used in our tag methods at the same time).
The scheduler kernel (in C) would maintain a queue of threads, identified by
their VM instruction, and environment pointers.


For a full CSP implementation we would also need to write:

0) A C function that took a list of Lua functions and executed them in
   parallel, returning once all of them had returned.

1) A data object for IPC, with get() and put() methods, from which other
   objects could inherit. get() and put() would block until both had
   been called (in their different threads). Note that this need not be
   a buffer; a pointer used as a semaphore will do the job as we could
   "hide" the inter-environment memory-copy operation within the paired
   methods.

2) A mechanism whereby a thread could wait for one of a list of object's
   get() methods to become ready, then return an index specifying which
   one it was.

--  Mark Ian Barlow                Non-Linear Control Consultants Ltd.
    -----------------------------------------------------------------
    [hidden email]            Voice / Fax: +44 (0)1207 562 154

Reply | Threaded
Open this post in threaded view
|

Re: multiple interpreters x multiple threads x multiple environments

David Jeske-2
On Tue, Sep 09, 1997 at 08:21:07PM -0300, Mark Ian Barlow wrote:
> In message <199709091844.PAA08845@server02> [hidden email] 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) + [hidden email]