[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: implementing a future in lua
- From: Asko Kauppi <askok@...>
- Date: Tue, 30 Dec 2008 12:29:29 +0200
Lua Lanes handles multithreading essentially as a future (though I
think that term is not mentioned in its documentation). Lanes are
presented as function calls that will execute in other OS threads.
Their results are available as an array, reading of which will pend
until the results are actually there. Yes, this does simplify
multitasking a lot.
You can pass these "futures" (= lane handles) further to other lanes
etc. essentially making the whole process rather transparent and -
You might want to experiment on top of it?
Personally, I don't see Lua needs this (or any OS threading support)
built in. Simply because it can be done as a module s.a. Lanes is.
btw, nice to see more Chinese on the mailing list recently! :)
李慧霸 kirjoitti 30.12.2008 kello 9:07:
I'm doing research on language constructs. And I'm going
to implement a Future mechanism in lua (taking lua as a
testbed). The Future mechanism can be introduced as:
"The construct (future X) immediately returns a future for
the value of the expression X and concurrently begins evaluating
X. When the evaluation of X yields a value, that value replaces
the future. The future is said to be initially undetermined; it
becomes determined when its value has been computed. An operation
(such as addition) that needs to know the value of an undetermined
future will be suspended until the future becomes determined, but
many operations, such as assignment and parameter passing, do not
need to know anything about the values of their operands and may
be performed quite comfortably on undetermined futures. The use of
futures often exposes surprisingly large amounts of parallelism in
As I'm only a beginer of lua and I'm not familiar with its VM
implementation, can anyone here give me some advice? Thank you!
I have read some documents and the source code, and will begin
And I wonder whether is there an interest of adding this feature to
lua. There seems to be little modification to the language itself,
all that is needed to do lies in the VM and library routines only. So
the future construt is not likely to break existing code.