[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: multiple interpreters x multiple threads x multiple environments
- From: Mark@... (Mark Ian Barlow)
- Date: Tue, 09 Sep 1997 23:20:08 GMT
In message <199709091844.PAA08845@server02> firstname.lastname@example.org 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.
> 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
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
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.
Mark@nlcc.demon.co.uk Voice / Fax: +44 (0)1207 562 154