Re: Tuna now in module form

[curt <curt@...>]

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)
> >
> > -Curt
>
> 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.

-Curt