Re: safely buffering Lua data between (system) threads & lua_States?

[Asko Kauppi <askok@...>]

I'll be needing this soon, writing sort of multitasking framework,  
where each state would deal with its own area, and communicate via  
messages.

I thought to do it / use a module that does it as follows:    ([]  
marking optional params/return values)

  h= open( myid_str )				-- establish a postbox for this state, with  
the given name (unique)
  bool= h:send( toid_str, msg_id [, ...] )  	-- send data (_not_  
userdata) with default priority (0)
  bool= h:send_prio( prio_int, toid_str, msg_id [, ...] )  -- place  
ahead of queue, if prio > 0
  [msg_id [, ...]]= h:poll( [msg_id] )		-- poll if there's a message  
(of specific id)
  [msg_id [, ...]]= h:receive( [msg_id] )	-- read out a message, to  
this state
  h:close()					-- thanks for the Fish!

The message passing would use serialization (placing tables etc. into  
string format, extractable back in the other state). There would be  
an unlimited queue for each such postbox, and the state/thread would  
itself need to read incoming messages, normally as part of its main  
loop.

Has anyone got an implementation, already?  :)

-asko


Javier Guerra kirjoitti 16.9.2006 kello 5.28:

> On Friday 15 September 2006 7:15 pm, Luiz Henrique de Figueiredo  
> wrote:
> > > How much can I copy Lua data around between distinct
> > > states (assuming thread safety is managed correctly)?
> >
> > If you have got your locking right, you can use lua_xmove if the Lua
> > states are related (ie, children of the same Lua top state).
>
> it would be great if there was any way to do that for unrelated Lua  
> states.  i
> guess it's not a trivial thing, unfortunately.
>
> in fact, each time i try to think how would that work, it's hard to  
> even
> define a 'desired' specification (how deeply to copy, what to do with
> userdata, metatables, upvalues, etc)
>
> thinking "the other way", a finer-grained lock for better  
> concurrency between
> related states seems more promising in the long run, but that's far  
> far away
> from my comfort zone.
>
> a third approach is to have some communications API between states,  
> hopefully
> something better than single values.  ideally, some way to define  
> 'shared'
> data.  then the problem becomes how 'contagious' should the  
> 'shariness' be...
> still no good ideas at the horizon.
>
> --
> Javier