I relatively new to web workers (simply had no need until now) and I did a lot of research and think I get the basics...
But :-)...
I'm stuck and hope for definitive input.
I'm rendering a graphic representation of an audio-file with the WebAudioAPI into an SVG. NO rocket science and it works to my satisfaction. With larger Audio-Files however it would be great to do it an web worker, The problem I have is however that inside a web worker I do not have access to the window object, and therefore I cannot access the AudioContext, which I would need to decode the raw data into an AudioBuffer. Is there another way to do it or a way around?
No, it is not possible to use WebAudio in a Worker. You will have to use the main thread with WebAudio and then transfer the data you need to the worker.
But see also the spec issue on supporting AudioContext in a Worker
Related
I have an user interface and provide a button to the user, which executes the function longComputation(x: A): A and updates then the user interface (particularly the model) with the new result. This function may take longer to compute the result and should therefore compute in parallel.
Diode provides me with Effect, PotAction, and AsyncAction. I read the documentation about Effects and PotActions/AsyncActions, but I cannot even get a simple example to work.
Can someone point me to or provide an simple working example?
I created a ScalaFiddle based on the SimpleCounter example. There is a LongComputation button, which should run in parallel; but is not.
In JavaScript you cannot run things in parallel without using Web Workers because the JS engine is single-threaded. Web Workers are more like separate processes than threads, as they don't share memory and you need to send messages to communicate between workers and the main thread.
Have less than 50 reputation to comment, so I have to create a new answer instead of commenting #ochrons answer:
As mentioned Web Workers communicate via message passing and share no state. This concept is somehow similar to Akka - even Akka.js exists which enables you to use actor systems in ScalaJS and therefore the browser.
Workers JSNI at GWT svn
It looks like WebWorkers have not been fully implemented yet. I know that elemental is in early stage of development but might be someone already have tried to make it works?
The problem with web workers is that they don't really fit the standard GWT/Java model - in my opinion they barely fit the standard JS model.
Web workers work by passing data back and forth between what are essentially different JavaScript VMs. That data must be in the form of a string, and each worker has to load its JS separately. This means that no variables declared in one worker (or the main page) is accessible from another, unless it is passed as part of the string data, pushed back and forth between workers.
So how does this work when you consider GWT/Java? From the Java perspective, this is not equivalent to multiple threads, but multiple JVMs! The different processes can only communicate by passing Strings (or more importantly, not Java objects) back and forth, and cannot share any other state. Even static variables might be different between the two virtual machines.
From the link you posted, check out the source of JsWorker - you can create an instance of this via JsWindow.newWorker with the url of the JS script to start with, and JsWorker supports methods to listen for responses, and to send it messages to give it work to do.
That script could be a GWT compiled object - but it would be a separate module and entrypoint than the original app, so that it only has the code it can reasonably run, and doesn't try to start drawing on the page when it loads. It would probably need to use a linker that would only load the JS, and wouldn't assume an iframe on the 'page'.
The GWT-NS project has some web worker samples already, built using their own linker to construct js files to load to load in the worker, and some other convenience pieces as well.
I'm very new to Node.JS and asynchronous programming and have a challenging question. I want to fork a process from Node and then shoot that output back to the browser with Websockets, specifically the Sockets.io library. What is the best and most robust way to handle this?
The data isn't mission critical, it's just for updating the user on status. So if they leave the page, the socket can close and the child process can continue to run. It'd also be neat if there was some way to access the socket via a specific URL in Express and come back to it later (but that may be another days work).
Use the Redis Store support of socket.io:
var RedisStore = require('socket.io').RedisStore;
var io = require('socket.io').listen(app);
io.set('store', new RedisStore());
The socket.io library use redis server to storage the data and the events.
I'm working on a new iPhone/iPod app that includes the need to do web services requests. I've found methods for doing these requests synchronously, or asynchronously by setting the controller as the delegate. What I'd really like to be able to do, though, is to create a single class that can handle all web requests for the whole application, and just create an instance of that class when I need to use it. That way, cookies and common pieces of code can be handled in one place, rather than all over the app.
So far the only thing I thought of that could accomplish what I'm trying to do is to create a new thread that handles the request synchronously within itself, then sends a message back to the calling controller once the request is complete. Is there a better way to accomplish what I'm trying to do?
Cookies are already a shared resource.
I would suggest reading the URL Loading System Overview to get an idea of how Apple set everything up. From what you describe, you want something very similar to how they have set up the system, maybe with a Singleton class for the connection. You can also look at ASIHTTPRequests which is a good wrapper around all of the connections stuff.
I would not suggest writing my own code here. Lots and lots of people have solved this problem for you.
I am currently trying to build a (simplified) stock app (like the one built-in on the iphone). I setup a simple server with a REST-interface which my app can communicate with.
However I am struggling to find the right/best way to build this kind of (streaming data consumer) client on the iphone.
My best bet at the moment is to use a timer to regularly pull the xml payload from the server (the connection is async but the xml parsing is not therefor the interface is blocked sometimes. I am a bit shy of thread programming since I learned some lessons the hard way on other platforms).
I read about websockets but it is not clear for me if and how they are supported on the iphone.
How would you do it?
Any hint would be appreciated, Thanks.
websockets aren't going to help you -- that's a server-side technology to make a socket-like interface work over HTTP.
If you don't want to block the GUI, you need to use another thread. You are right to be scared of doing this, so share as little as possible (preferably nothing) between the two threads. Use a message passing mechanism to get information from the background thread to the UI thread.
Take a look at ActorKit: http://landonf.bikemonkey.org/code/iphone/ActorKit_Async_Messaging.20081203.html
Take a look at this question.
It talks about asynchronous vs synchronous connections. You will want to use an asynchronous call to get your data so you don't lock up your UI. You could use that in conjunction with a polling timer to get your data from the server.
You can find more info about the NSURLConnection in apple's documentation here