Again, the workerss

[gen-failure]

Hi,

I know this topic was discussed many times ago, but I would like to ask bit more specific question.

I am in a situation, when I need to implement 3d app build in three.js and physi.js. Physi.js depends on ammo.js which depends on webworkers.

Because I really need to get my web worker, I was thinking about creating some very limited implementation by myself. But, I am quite a green in ObjC and iOS so I would like to ask.

As far as I see, there are two main tasks in implementing workers.

1. Creating a class which is offspring of EJBindingBase, have it's own javascript context as object variable and implement basic messaging systme (postmessge, onmessage) and async communication
2. Move the Worker JS Context threadable (or what is right term in objc world) to get some performance boost.

Second part might be tricky, but making fake worker for compatibility issue can be quite easy. Or is there some problem I am not able to see?

[weepy]

I need something similar. Can you expand on point 2? I don't quite follow what you mean.

On Tuesday, September 17, 2013, Michal Koudelka wrote:

Hi,

I know this topic was discussed many times ago, but I would like to ask bit more specific question.

I am in a situation, when I need to implement 3d app build in three.js and physi.js. Physi.js depends on ammo.js which depends on webworkers.

Because I really need to get my web worker, I was thinking about creating some very limited implementation by myself. But, I am quite a green in ObjC and iOS so I would like to ask.

As far as I see, there are two main tasks in implementing workers.

1.

Creating a class which is offspring of EJBindingBase, have it's own javascript context as object variable and implement basic messaging systme (postmessge, onmessage) and async communication 2.

Move the Worker JS Context threadable (or what is right term in objc world) to get some performance boost.

Second part might be tricky, but making fake worker for compatibility issue can be quite easy. Or is there some problem I am not able to see?

— Reply to this email directly or view it on GitHubhttps://github.com/phoboslab/Ejecta/issues/231 .

[gen-failure]

I am not expert for ios plattform., but my point is:

The reason why we need workers at all is to be able to move more complicated mathematical operation to another cpu or core and I don't know how difficult is to implement that. But creating independent script container and allowing basic js messages (onmessage,onerror,postmessage) error does not sounds too complicated to me. So I wanted to ask more experienced objc developers where's the catch.

[w33py]

It don't think it should be particularly difficult. Am planning to give it a go when I get a chance over the next few weeks. But I would be interested to know if there are any catches too.

[gen-failure]

Technically, it should be possible to create second, non displayed canvas, load some basic js code which will implement the msg api and use the second canvas as worker... I am just not sure who difficult would it be to force these to ejecta canvases to speak together :)

[w33py]

i dont think u'd need an Ejecta canvas - a JavascriptCore instance would be fine?

On Wed, Sep 18, 2013 at 1:39 PM, Michal Koudelka notifications@github.comwrote:

Technically, it should be possible to create second, non displayed canvas, load some basic js code which will implement the msg api and use the second canvas as worker... I am just not sure who difficult would it be to force these to ejecta canvases to speak together :)

—

Reply to this email directly or view it on GitHubhttps://github.com/phoboslab/Ejecta/issues/231#issuecomment-24660887 .

[drkibitz]

@w33py is correct. There should not even be a reference to window in a worker. There are just a few globals in a addition to the defaults which are most notably self, postMessage, and importScripts. But I would also like to note that both self and postMessage should also be defined on the main thread where self = window. On the main thread we just need the Worker constructor, leaving out SharedWorker for now since the implementations are all in flux, and it doesn't really make sense for something like Ejecta anyway.

[drkibitz]

I guess something that we may be overlooking is the implementation of Transferable Objects, I have no idea how that would be done.

[w33py]

Presumably the "window" in the Worker wouldn't be equal to the "window" in Ejecta ?

Otherwise we'll have synchronisation issues.

On Wed, Sep 18, 2013 at 4:21 PM, Dr. Kibitz notifications@github.comwrote:

@w33py https://github.com/w33py is correct. There should not even be a reference to window in a worker. There are just a few globals in a addition to the defaults which are most notably self, postMessage, and importScripts. But I would also like to note that both self and postMessage should also be defined on the main thread where self = window. On the main thread we just need the Worker constructor, leaving out SharedWorker for now since the implementations are all in flux, and it doesn't really make sense for something like Ejecta anyway.

—

Reply to this email directly or view it on GitHubhttps://github.com/phoboslab/Ejecta/issues/231#issuecomment-24672847 .

[drkibitz]

There should not even be a reference to window in a worker

was the first sentence in my comment. self = window was referring to the main thread.

[drkibitz]

Here's something I myself just found out about http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#canvasproxy

[incanus]

I'm curious if anyone has started down the path of implementing even a light version of web workers in Ejecta. I have, via:

• Creating a mock Worker.js that's included in the Ejecta environment
• Creating some lifecycle events in it such as kickoff, message posting, and (stub) termination
• Binding above lifecycle functions into C functions in Ejecta
• Converting message posts to NSDictionary objects so that I can convert back and cross contexts
• Kicking off worker work into Grand Central Dispatch/NSOperationQueue objects with their own JSContextRef for concurrency
• Posting messages back to the parent at worker end (back on the main thread)

I've got the above working for very basic JS in the worker. However it's a huge pain to debug and I'm currently running into stack recursion errors. My JS is rather elaborate but it would be useful to share knowledge with anyone else who's tried going this route.

[finscn]

The web worker is helpless for most html5 games . Maybe the real multi threading is helpful , but web worker is not.