Lua Lanes with MemoryEx

[Eagle]

I would like to take a look to contribute

for Sure, bound to be code improvements- optimising, additions ,
all improvements are welcomed and encouraged

btw: ThreadApiEx has no separate lua file and all functionality is kept within
the ThreadApiEx global table

[webultra]

I would like to take a look to contribute

[Eagle]

Quick Update: ThreadApiEx v1.0.0.0 will be released on 19\08\2014

here's a snippit:

General:
ThreadApiEx Package Eagle Release 1.0.0.0
ThreadApiEx Package is based on 'Lua Lanes' (v2.2.0.1) source code, recompiled with modifcations to 'ThreadApiEx.dll'
ThreadApiEx is compiled for and offerred as a 'fresh start' option for multi-threading in IR runtimes
and should be viewed as an independent breakaway from existing original 'Lanes' modules and related lua code
ThreadApiEx is open source and is in compliance and aligns with the Lua Lanes licensing scheme.
(Lua Lanes sources and licensing scheme can be viewed at: https://github.com/LuaLanes/lanes)

Dependency requirement: MemoryEx plugin v2.2 or later, created by Immagine Programming, IS loaded

Additions:
added: ThreadApiEx core version to returned ThreadApiEx table via ThreadApiEx.getVersion *see below
added: enforce required ThreadApiEx module must be v1.0.0.0 (base version of ThreadApiEx)
added: Various 'Thread' helpers to create,run and monitor a thread (no page timers are used)
(one main feature is auto Run a child Thread in ThreadApiEx Thread Wrapper(itself a Thread)
added: Many Helper functions for dealing with Pipe objects and Timers for Intercommunication between States
added: Ability to Lock\UnLock\Pause a running Thread
added: Helper functions for Ability to run multiple Threads in 'Batch' mode (if one returns an error others won't continue)
added: ThreadApiEx.LoadActionPlugin() to load any valid Action plugin within a thread function
added: MemoryEx plugin functionality compatability fix for use in Thread main functions;
added: MemoryEx plugin loading within a Thread via a call: ThreadApiEx.LoadActionPlugin(ValidString\\path\\to \\MemoryEx.lmd);
added: MemoryEx 'Library' support via LibrarySet and LibraryGet for enabling acccess by any Thread
added: Opened Libraries can be accessed and independently closed within any Thread or sub-thread via pre-assigned Pipe accesses
(without closing or destroying the Originally Set Library(s) )
added: Shaired Memory Thread Creation functionality (for InterState Communication etc. between Main state and Thread(s) )
added: Global Timer functionality via Subclassing(MemoryEx plugin) of Debug Window(the default, if a valid handle is not provided)
or any coded Window Handle and enabled via a call to: ThreadApiEx.GlobalTimerEnable(MyHandle) - ThreadApiEx.GlobalTimerDisable(MyHandle)
(reference the other GlobalTimer functions to control individual timers etc: start(id,cycle time) or stop a timer(id) etc )
added: Tips and Tricks some basic on how to construct thread functions and make full use of Upvalues etc.
(including customising and accessing exposed thread finaliser function on Thread Close)


Fixes: Removed undocumented Recursive upvalue restriction discovered in Lanes v2.2x Source code (removed by author of Lua Lanes from v3.4.2)
Minor Improvements to thread loading performance.

Issues: Improperly coded or invalid data types in an IR action in a running Thread function can cause the Application to Crash.
(appears ThreadApiEx api unable to properly perform data validation for missing parameters and push onto Thread error Stack)

TODO List:
Add more improvements and fixes from later versions of Lanes v 3.4.2 and later as a goal

-------------------End of ThreadApiEx Package Description---------------------------------------------------------------------------------------------

[Eagle]

Side note for you BAS,

Only reference to your MemoryEx plugin in this module is to have it 'thread' friendly and usable, callable
from within a thread function, which is part of what ThreadApiEx can do, the full path of your MemoryEx plugin
must be known to ThreadApiEx so it can be 'required' by a thread or set as a pipe object to pass between
Main App state and any thread states.

It would be great if not already available, the path to MemoryEx plugin could be exposed or made available
in the App main state so it can be referenced easily.
cheers

[Eagle]

Unfortunately I would want MemoryEx to remain a separate resource. Redistribution is only allowed when used as plugin as downloaded from imagine-programming.com. Redistribution as part of another plugin, package, library or module is not allowed.

Absolutely understand BAS, i was going to contact you first, for discussion-permission etc., if it was to be seriously considered and a full plugin. Going the LH file direction would probably be the pathway, however the ThreadApiEx.dll
module and lua code would always be distributed as a part of the project, as mention above(so no secrets etc)

cheers

Martin

[Imagine Programming]

Unfortunately I would want MemoryEx to remain a separate resource. Redistribution is only allowed when used as plugin as downloaded from imagine-programming.com. Redistribution as part of another plugin, package, library or module is not allowed.

[Eagle]

MemoryEx compiler allows for a Lua module to be embedded as a string within the LH file so really if an LH file is used it could just be the one file for lanes and the wrapper functions..............

Kill threads(s) <-- Looking forward to that the most as I've got a few test applications performing really well except if a Lane happens to be running on exit then games over and a crash is guaranteed.

Yeah embedding the dll is the idea for sure (in fact the dll source code makes no references to lanes or keepers at all)
that keeps it entirely isolated and functional if, for some reason, original lanes module is running.

any running threads at APP close are supposed to be killed and GC'd by lanes module when detects Main state has
a lua_close call or similar. Could be something in your lane thread function or timer that is locking in a wait state
or there is a linda que bottle neck.

if IP is happy and ThreadApiEX is a full plugin, the MemoryEx plugin would be an embedded resource too.

[Shrek]

MemoryEx compiler allows for a Lua module to be embedded as a string within the LH file so really if an LH file is used it could just be the one file for lanes and the wrapper functions..............

Kill threads(s) <-- Looking forward to that the most as I've got a few test applications performing really well except if a Lane happens to be running on exit then games over and a crash is guaranteed.

[Shrek]

Registered :yes

[Eagle]

ThreadApiEx (as it will be known) is closing in for a beta test, coming to a store near you.

Movement away from all 'lanes' references to threads reference, a specially 'IR runtime friendly'
compiled ThreadApiEx.dll will be provided with full ThreadApiEx library of functions.

Much more control of threads and stable reliable communication between threads, sub threads
and the Master state. Multiple thread finish waits, Kill threads(s) -really kill em from runtime allocated memory.

Much emphasis placed on global state filtering options, monitoring of threads in a master thread
(no while loops or page timers needed). Many helper functions for 'Pipes' (formerly 'lindas') creation, control, reset,
sendto, receive, set and get pipe data slots, slot timers functionality and more.

MemoryEx plugin compatibility built in with full: require ('MemoryEx') capability, transfer of Librarys etc
between states, creation of a shared memory thread(s) fully accessable between states and more.

Additional helper functions added like, Application PID and Hwnd, Application Page hwnd, Debug Window hwnd,
Application wide global timer(s) (using subclassing) creation and control functionality.

Full source code for a Plugin or LH file and the latest dll will always be included in each release

Beta testers register your interest in this Thread, pardon the pun haha

[Eagle]

Hi webultra,

yeah had similar thoughts, (not editing lanes.c though, food for thought hehe)

I'll take note of your work and thanks

[webultra]

Hi eagle,

I remember I wrote something like that a few years ago at forums.h . Basically what I did was kind of event manager triggered by a linda:set or :get call by editing the lanes.c file and by using lanes timer (in a new lane). My main idea was to create callbacks to new lanes without using the default AMS page timer.

The usage was something like:

laneFunction = easyLanes.newLane(fn, ..., callbackWhenLaneIsFinished)

BTW, you-re doing a great job with lua lanes

[Eagle]

sorry for delays on this, am working on a hybrid of easyLanes without using the page timer
to monitor threads(use a specialised thread instead) and various other tweaks, additions.
for example: function to create and ignite a thread in one call,
Built in specific MemoryEx thread creation functionality (includes automatic 'MemoryEx' thread fix)
Its internal table of functions will be accessable via a call to lanes.Threads as part of the lanes public api table

eg: local myThreads = lanes.Threads; -- lanes internal thread creation 'table of functions'
local TMex = myThreads.CreateMemoryExThread(usual lanes compat params, true) --to create and ignite


Now have loaded dll libraries via MemoryEx from main state(if desired) accessable by threads.
(no more loading in each new thread etc.)

will post all functionality here for testing by those interested and upon feedback and a welcomed
collaborative effort here, the main 1st release version template can be posted in the Showcase
section under a new heading 'Using Lua Lanes Threads'.

of course the whole thing could be coded into a plugin or LH module at some point - plug for Bas

[Eagle]

FWIW:

no issues at my end with linda set and get
but yes a bug in the code where lanes.timers function was not being populated to the lanes table,
however stay tuned as have done some extensive testing and rewritten lua lanes loader,
now a function call with no loadstring(depricated in lua 5.2 fwiw - 5.2 you just use load)

will post this and other stuff in the show case threads with a downloadable Lanes Package
(this package will have Bas' MemoryEx plugin in mind as well, so you will be able to load it
to any lane via a simple require ('MemoryEx') call or via a compiled linda table )

other stuff using Lua Lanes will be included in the package - will post in cuppla days

[Shrek]

^^, linda:set and linda:get don't seem to be working with EasyLanes used with your loadstring and Lua Lanes v2.2.

One other thing with MemoryEx in the lane loaded as in post 28, after a while for a random reason it will error out saying 'SendMessageA not found in loaded module' and it's a bit odd given it happily sends messages to windows previously, what could be the reason for forgetting what functions have been loaded in the dll?