lua-users home
lua-l archive

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



It looks like register, post and receive functions of LuaTask.
But you are talking about separated processes instead of threads, isn't it?
Not really. What I have in mind is similar in concept to the notion of processes, and an OS, but they will actually be run as threads in a single process. This way, they can use a C module (malloc/free) for data exchange.
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.
Would be one way; I'm trying to make this as light as possible, and as async as possible. No shared state would be required in my module- planned approach; in fact I do have C code for doing this already, just checking if there's a standard solution I've missed (s.a. LuaTask could be).
But I don't know what is the best way to connect those unrelated Lua states. 
Any suggestions will be welcome and appreciated.
This message thread shows, in my opinion, a worrysome situation LuaLand has come to. There _are_ open source building blocks, but they're not entirely documented, or too 'well' documented, or... There's no clear place for shopping for the right module. We've in effect created an open source bazaar within the community, with lots of overlap. That is good, unless it brings to the "ah, there's N solutions, none really suiting, so.... I'll do my N+1".
We need LuaRocks to solve the arisen condition, and _uniform_ documentation of what a module actually promises to do, and what it's platform requirements are, how speedy it is, etc... :) 

-asko



Regards,
Daniel



Daniel Quintela kirjoitti 17.9.2006 kello 17.30:


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 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



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.

Regards,
Daniel