Here's a simple worker thread API for flash/js/neko/cpp

[Rezmason]

Happy Winter Solstice! I've got a present that I think you'll like: basic cross-platform workers!

https://github.com/Rezmason/Golems

In a nutshell, this will let you kick work out of your app's main thread and event loop, without having to poke around the web for gists. :-D If you're making a game with an AI or an audio signal processor, or some hardcore personal finance software, this code will hopefully make it easier than ever to free up your main thread and keep things responsive. (And if it doesn't, you can certainly edit it until it does.)

The basic idea is, if you want to write code that can run in a worker thread, you extend the BasicWorker class and override its receive functioIn to get things going. Don't write that main function; BasicWorker handles the entry point. (I agree that this is weird, but the alternative made it really simple for folks to shoot themselves in the foot.)

To use that worker, you make an instance of a BasicBoss subclass in your main app, start it up and you're golden. :-)

Now, depending on your target platform, the constructor for BasicBoss accepts either a Bytes object containing the worker SWF or JS file, or a class that extends BasicWorker. I think that's annoying and error-prone, so I wrote the Golem class.

Golem is nuts. It's a macro that takes a string like './projects/MyWorker.hxml', runs over to that HXML file, finds a build target inside that's labeled ##GOLEM## that targets the same platform as the current build, and if the platform is Flash or JavaScript, it'll run that build target, find the output SWF or JS file and adds that to the main project as a resource. And then it'll return it. You don't even need to deal with fetching the resource. Golem isn't necessary, but if you've got multiple target platforms, you might want to give it a shot.

I literally just put this online, and I'm interested in feedback. So far, I want to thank clemos and David Mouton for the gist they were playing with in a recent thread, and Sven Bergström, who helped me figure out the message passing for neko and C++.

(Yes, it's completely OpenFL compatible. Why wouldn't it be?)

[Justin Donaldson]

I'm looking through the source and this looks neato.  Plus I like the ideas of Golems working at a TempAgency.  They've got to do what they can in this economy.

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/groups/opt_out.

[Rezmason]

On Saturday, December 21, 2013 11:29:02 PM UTC-8, Justin Donaldson wrote:

I'm looking through the source and this looks neato.  Plus I like the ideas of Golems working at a TempAgency.  They've got to do what they can in this economy.

I have an unorthodox way of naming things... ;-)

I've added a prime number example, which I pilfered from the WHATWG. Seems like the Flash target doesn't terminate easily when the work being done occurs in tight loops. I just got another example from Sven, which I'll upload soon.

[Nicolas Cannasse]

Le 22/12/2013 07:55, Rezmason a �crit :
[...]

> Now, depending on your target platform, the constructor for

> *BasicBoss* accepts either a *Bytes* object containing the worker SWF or
> JS file, or a class that extends *BasicWorker*. I think that's annoying
> and error-prone, so I wrote the *Golem* class.

It should be feasible to actually automate this by somehow using the
same context for both the main thread and the worker thread, which would
simplify things by having a single file to deploy.

That might require an additional "if( Golem.startWorker() ) return" in
main()

Best,
Nicolas

[Rezmason]

Ideally, Golem.rise would optionally accept an expression, wrap it in a BasicWorker subclass and then (if the target is Flash or JS) compile it into a SWF or JS file. Then a worker project wouldn't even be necessary.

Usually, though, most people who're using workers probably maintain them as separate projects for testing purposes anyway. Would anyone else actually use Golem.rise({codeblock})?

[Alessandro Bianco]

I know it's an old topic but ... i definitely would use inline code blocks

[Nathan Hüsken]

Me too!

On 10.09.2014 10:06, Alessandro Bianco wrote:
> I know it's an old topic but ... i definitely would use inline code blocks
>
> On Sunday, 22 December 2013 19:27:45 UTC, Rezmason wrote:
>>

>> Ideally, *Golem.rise* would optionally accept an expression, wrap it in a
>> *BasicWorker* subclass and then (if the target is Flash or JS) compile it

>> into a SWF or JS file. Then a worker project wouldn't even be necessary.
>>
>> Usually, though, most people who're using workers probably maintain them
>> as separate projects for testing purposes anyway. Would anyone else

>> actually *use* *Golem.rise({codeblock})*?
>>
>

[Rezmason]

Okay, maybe it's time for me to polish this piece of code up a bit. I'll post a link to a branch soon. Someone asked me to make it a haxelib recently, too.