Re: another try at multithreading

[Asko Kauppi <askok@...>]

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