lua-users home
lua-l archive

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

On 2/15/2012 3:02 AM, Ezra Sims wrote:
On 2/14/2012 11:21 PM, curt wrote:
Okay I figured out the problem, works great on my x86 test box... with -O1 .. -O2 segfaults on exit. Sorry but homey don't play that game, I will be tracking that down; pretty sure its related to my handling of the EBP register. I have uploaded it as 0.4.2[unstable] and as far as I can tell x64 and windows x86/x64 are unaffected and the examples function correctly (as does linux x86 at the current optimization level of -O1)


Cool, I'll give it a shot later tomorrow. I hadn't thought to mess with the optimization flags.

As a point of curiosity in the meantime, could you explain how Tuna interacts with the Lua state during blocking functions? Using a crappy homebrew thread API I was able to fire functions across threaded states (using a really basic lock-everything approach) without too many problems, pretty much no matter what either state was doing. The thread could be in the middle of a sleep loop or Verse's event loop and I wouldn't have to worry waiting for it to complete or yield unless a block was desired. Can I expect about the same behavior from Tuna, or would I need some extra action within those loops?

If I understand your question correctly, using two different states (two separate threads, for Tuna) then they are not allowed to interact in any way other than sending messages to each other, the same as Lanes. They will process simultaneously and never lock each other, you don't need to do anything special.

If you mean to different Tasks withing the same state (Which Tuna does) then only one can process at a time, they share the same global space and are scheduled cooperatively. If you have a loop in one, it will execute until it yields (tuna.yield() for example) or does something else that asks Tuna to do something for it, like sleep or send/receive a blocking message.

Locking is not required since the underlying c-stacks are held separately, they preserve all state information when yielded, and mutexes are not requires since when a task is operating it cannot be interrupted unless (as I just mentioned) it explicitly yields.

Does that help? I'm not sure I am answering what you are asking.