[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Tuna now in module form
- From: curt <curt@...>
- Date: Wed, 15 Feb 2012 14:42:16 -0500
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
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.