search

jinroh / kadoh

The Kademlia DHT in Javascript for Node.js and Browsers
http://jinroh.github.com/kadoh
Other
242 stars 31 forks source link

Using WebWorkers ? #35

Open jinroh opened 12 years ago

jinroh commented 12 years ago

Maybe we could use webworkers to run our node object since we don't need any DOM access and we would take advantage of multithreading.

stackoverflow

  • John Resig (of jQuery fame) has a bunch of interesting examples of using web workers here - games, graphics, crypto.
  • Another use is Web I/O - in other words, polling URLs in background. That way you don't block the UI waiting for polling results.
  • Another practical use: in Bespin, they’re using Web Workers to do the syntax highlighting, which you wouldn’t want to block your code editing whilst you’re using the app.
  • From Mozilla: One way workers are useful is to allow your code to perform processor-intensive calculations without blocking the user interface thread. As a practical example, think of an app which has a large table of #s (this is real world, BTW - taken from an app I programmed ~2 years ago). You can change one # in a table via inpput field and a bunch of other numbers in different columns get re-computed in a fairly intensive process. The old workflow was: Change the #. Go get coffee while JavaScript crunches through changes to other numbers and the web page is unresponsive for 3 minutes - after I optimized it to hell and back. Get Back with coffee. Change a second #. Repeat many times. Click SAVE button. The new workflow with the workers could be: Change the #. Get a status message that something is being recomputed but you can change other #s. Change more #s. When done changing, wait till status changes to "all calculations complete, you can now review the final #s and save".
alexstrat commented 12 years ago

OUUUUUIII !! J'avais ça vu et gardé sous le coude, mais j'avais oublié de le ressortir..

jinroh commented 12 years ago

http://caniuse.com/webworkers

alexstrat commented 12 years ago

Actually, we do need DOM almost everywhere.

Strophe and our XML-RPC use document.createElemement which is unavailable in webworker. Too bad bcause I think the Reactor would have been the most interesting part to be executed in worker.

And value management uses localstorage which is part of the DOM.

I don't think we have much to earn by using webwokers for the RoutingTable or the Node, or even for hash computation. Pour les webworkers ça me parait un peu dead.

jinroh commented 12 years ago

True..

jinroh commented 12 years ago

What is our next “big thing” to do ?

alexstrat commented 12 years ago

Strophe issue talking about that : It seems to be possible (jsut possible) to have Strophe in web worker, but that remains limited in our case.

The solution is certainly in a SAX parser wich is event-driven like web workers and DOMless implemented. See #41.

piranna commented 11 years ago

In ShareIt! i'm using a webworker to do the hash of the files without problems... Just using it like a thread, calling it with postMessage to add the files on a queue, process them one by one and returning the hash to the main script with postMessage and a message event.

ghost commented 11 years ago

I think piranna has the right approach. TO integrate Web workers you find parts of your code which are computational and run those inside a web worker. You only using message passing between the windows thread and the web worker thread.. You can thin of each as separate applications.

My hope is that you integrate more into web workers. This will allow this project to work well on firefox OS. Firefox OS apps should use web workers as much as possible to maintain the GUI speed of the whole mobile phone GUI.