Re: Tuna 0.4.1 released

[Curt <curt@...>]

On 2/13/2012 5:56 PM, Michal Kottman wrote:
> On 13 February 2012 23:01, curt<curt@northarc.com>  wrote:
> > Tuna 0.4.1 includes support for Win64 architecture (what a fun week it was
> > learning x64 assembly, interesting stuff!) and has some performance tweaks
> > for even faster stack swapping. Also added a few more examples and included
> > VC2005 build support as well as the VC2010
> >
> > Some API additions too, its all here: http://northarc.com/tuna
> >
> > As ever, all feedback is welcome, including any suggestions for performance
> > comparisons.
> I am not sure if I missed anything (and do not want to sound
> ignorant), but I didn't quite understand if it is possible to use Tuna
> directly from the Lua interpreter, or do I have to create a custom
> Tuna-spawned interpreter?
Currently you need to spawn an interpreter with the Tuna API, which 
installs the 'tuna' namespace. Once you do that everything can be run 
from the lua-side without further C intervention.

but I _DO_ I want to create a binary include such that:

local tuna = require 'tuna'


Will be all that's required from the standard interpreter. This is on 
the roadmap (such as it is.. "get the darn thing working" sorta came 
first :). I expect this will be possible in the next few weeks (sooner 
if someone really wants it).
> You say there is a 'lua-lanes'-like mode of operation, does it mean
> that I can something like this?
>
> local tuna = require 'tuna'
> local thread = tuna.startThread('*')
> local task = thread:startTaskFromBuffer(.....)
See above.

> Also, what is the difference between tasks and threads? Are threads
> directly related to OS threads?
Tuna initially starts a single [OS] thread of execution and within that 
single thread can create and switch between many (50,000+ is no problem) 
tasks. Like coroutines only one task can be resident and process at a 
time (cooperative multi-tasking). The difference from coroutines is the 
integration is seamless across the C api and (I think) more intuitive. 
This is accomplished by maintaining a stack for every task and swapping 
them in and out with actual OS-level context switches (here there be 
assembly)

Swapping in the worst case anyway; best case is a single pointer is 
changed for the context switch. Tuna maintains several (default 8 x 
1meg) actual OS stacks per thread and as long as there are fewer active 
tasks than stacks, no swapping takes place. (and with lazy copyback, no 
actual memory moves of any kind, it's blazing fast)

Tuna can ALSO spawn more OS-level threads, and within each of those 
threads run a separate bunch of Tasks (thus preemptive). The 'mailbox' 
functionality makes no distinction between separate tasks and separate 
threads and therefore functions across these OS threads and allows 
seamless communication, that's the 'lanes' part.

Tuna encapsulates both capabilities together so you mix and match to fit 
your application.

tldr; Tuna-threads are OS threads, thats the 'lanes' side. Tuna-tasks 
are not.

> Will it be possible to directly start a Lua function, instead of
> having to create it in a separate file or a string? something like:
>
> thread:start(function() print "Hello Thread!" end)
Sure! That's actually pretty easy to do (I think)

I have been pouring every spare second I have into this project for the 
past few months, with QA taking up most of it. You probably wouldn't be 
surprised at how subtle bugs can creep into this kind of code. Luckily 
chasing down mystic crashes under extreme loads is sort of my dayjob :) 
it remains as much a chew-toy as anything else, but you have made two 
excellent suggestions and I will see what I can do.

And thank you, that kind of sample code is exactly what I need, by the 
way, "I want to do *this*" is exactly the best way for me to know which 
directions to extend Tuna such that it is the most useful.

-Curt