lua-users home
lua-l archive

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



Doug Currie kirjoitti 20.6.2008 kello 21:40:


On Jun 20, 2008, at 2:23 PM, Alex Sandro Queiroz e Silva wrote:
Javier Guerra wrote:
On Fri, Jun 20, 2008 at 1:00 PM, Robert Raschke <rtrlists@googlemail.com > wrote:
On 6/20/08, Javier Guerra <javier@guerrag.com> wrote:
remember, even Erlang with its nice lightweight threads and message
passing, is implemented on top of shared data structures.
Sure, but with the added proviso of not doing destructive updates in
the language. That makes sharing data quite a bit easier. So, how
about a "single assignment" version of Lua?
sounds nice.  of course, i wouldn't know where to start.

"Single assignment" is the easier way to add concurrency, but it would turn Lua effectively into a functional language, changing much of its semantics.

Right. If you want Erlang, you know where to find it.

BTW, Erlang does have destructive update data structures (DETS, and bit arrays in HiPE, for example), which leads me to my (sug)question...

Could an in-memory SQLite database be used to efficiently provide shared Lua-semantics tables? I have not benchmarked (or coded!) this, so it is just a fantasy. SQLite now provides shared cache, optional read non-committed transactions for high levels of concurrency in a single address space. This probably does not scale particularly well to networked clusters (though it would work).

e


Absolutely.

Modules and the file system are shared resources of the states. The multithreading implementation needs to support modules (Lanes does, i.e. serializing calls to 'require') and the modules must not be explicitly non-multithreading ones (the regular C rules for multithreaded apps).

That said, I would see the usual SQLite binding being capable of used in this way.

Anyone done that?

-asko