[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: safely buffering Lua data between (system) threads & lua_States?
- From: Daniel Quintela <dq@...>
- Date: Sun, 17 Sep 2006 11:30:15 -0300
Asko Kauppi escribió:
I'll be needing this soon, writing sort of multitasking framework,
where each state would deal with its own area, and communicate via
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
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? :)
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
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
related states seems more promising in the long run, but that's far
from my comfort zone.
a third approach is to have some communications API between states,
something better than single values. ideally, some way to define
data. then the problem becomes how 'contagious' should the
still no good ideas at the horizon.
It looks like register, post and receive functions of LuaTask.
But you are talking about separated processes instead of threads, isn't it?
The idea of having a common Lua state in shared memory "connected" to
the threads/processes own states had been on my mind for a while.
You only have to move something from your own state to the shared one to
make it available to anybody.
But I don't know what is the best way to connect those unrelated Lua states.
Any suggestions will be welcome and appreciated.