[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: implementing a future in lua
- From: "Alex Davies" <alex.mania@...>
- Date: Tue, 30 Dec 2008 17:26:25 +0900
Hey,
How you'd go about it would depend on how seamless you want it to be. If
you don't mind losing the concurrent processing of futures, future's could
easily be added via tables, userdata or a custom type, with minimal changes
to the lua c code. (Would have to change the comparison code, arithmetic
handling could easily be implemented via metamethods). Wouldn't be hard at
all to do, and who knows might save the odd clock cycle when a value is
computed but never required, along with making good proof of concept. (Of
course on the stack the value would stay as a table, but you'd make it so
the value is stored away once the function has completed, making its access
quick).
To allow concurrency would be hard work. You could simulate it a bit by
representing futures with coroutines, with a coroutine dispatcher thread,
and each future/main thread yielding at key points - but it's a bit unwieldy
for this purpose. Would appear completely multithreaded though, with
expensive functions not blocking the code. And has the advantage that when
a good make-coroutines-concurrent patch comes along, it'd all work
beautifully.
Or if hung up on true concurrency now, could try representing futures as
userdata, with each userdata spawning a whole new lua state. You'd have no
access to globals, etc (but then how do these work in "futures"?), but
there'd be no inherent problems in running each state in its own thread.
Very expensive though.
To improve on that (concurrency within a lua state) would require everything
that simultaneous coroutines requires, so there isn't much point. Perhaps
look to lua lanes (which I believe defines global locks around pretty much
every lua function).
I'll be interested to see what you come up with though :).
- Alex