I have been working with teaching kids programming in Javascript using a combination of online and self made environment.
At some stage most of the kids encounter a time when they create an infinite loop. In days gone by. an infinite loop was expected to be a child's first program with
10 PRINT "Mike is cool"
20 GOTO 10
Writing something like that in JavaScript is problematic
while(true) {
print("Mike is cool");
}
Doesn't work because of the synchronous nature of JavaScript, and that's something that they will have to learn. The problem isn't that their program doesn't work as expected, but when they run their program the entire world stops!
Some Browsers have enough control remaining to close the window, some just Lock. If you are using an in-browser environment (like jsfiddle, jsbin etc) you don't have enough control to stop the rogue "task"
You can't audit the code beforehand (It literally is the halting problem), but is there any reasonable way of mitigating the symptoms?
The programming environment on Khan Academy seems to achieve this
http://www.khanacademy.org/cs/breaking/4804951998988288
What is it doing to handle the excessive run-time? How is it managing to do this while the while is still running?
You could accomplish this in a browser by using a web worker, which does not lock the UI thread of the web browser because the browser runs a separate thread for the web worker. Your looping code for the example would be run in the web worker.
Web worker threads are an HTML5 feature so this approach will not work on older browsers. You can set breakpoints and debug web workers, at least in Chrome and Safari. You can learn the basics of web worker threads at:
http://www.html5rocks.com/en/tutorials/workers/basics/
Related
I am building a calculator that makes lots of XHR calls and was wondering if placing these in a web worker, synchronously, would still lock the browser? It's my understanding these are handled in a different thread and shouldn't.
(I've built the algorithm asynchronously before, it's just very hard code to maintain and I only am looking to this option to keep the code more maintainable. I understand why it shouldn't be synchronous outside of a web worker.)
Without another processor available, it won't be as bad as it would be without Web Workers (because the OS can round-robin schedule the two threads to run interleaved even one on processor).
And with another processor available, the OS would ideally schedule it to run on that thread, and they would both run at full speed.
I have a touch screen kiosk application that I'm developing that will be deployed on the latest version of Chrome.
The application will need to make AJAX calls to an web service, every 10 minutes or so to pull thru any updated content.
As it's a kiosk application, the page is unlikely to be reloaded very often and theoretically, unless the kiosk is turned off, the application could run for days at a time.
I guess my concern is memory usage and whether or not a very long running setTimeout loop would chew through a large amount of memory is given sufficient time.
I'm currently considering the use of Web Workers and I'm also going to look into Web Sockets but I was wondering if anyone had any experience with this type of thing?
Cheers,
Terry
The browser has a garbage collector so no problems on that. as long as you don't introduce memory leaks through bad code. here's an article and another article about memory leak patterns. that's should get you started on how to program efficiently, and shoot those leaky code.
also, you have to consider the DOM. a person in SO once said that "things that are not on screen should be removed and not just hidden" - this not only removes the entity in a viewing perspective, but actually removes it from the DOM, remove it's handlers, and the memory it used will be freed.
As for the setTimeout, lengthen the interval between calls. Too fast, you will chew up memory fast (and render the page quite... laggy). I just tested code for a timer-based "hashchange" detection, and even on chrome, it does make the page rather slow.
research on the bugs of chrome and keep updated as well.
Let's say you log certain things on your nodejs app or on a browser.
How much does this affect performance / CPU usage vs removing all these logs in production?
I'm not asking because I'm just curious how much "faster" would things run without it so I can take that into account when developing.
It can cost a lot, specially if your application is hardly based on a loop, like a game or a GUI app that gets updated in real time.
Once I developed an educational physics app using <canvas>, and with logs activated withing the main application loop the frame rate easily dropped from 60fps to 28fps! That was quite catastrophic for the user experience.
Overall tip for browser applications is: Do not use console.log() in production for loop based applications specially the ones that need to update a graphical interface within the loop.
For Node: is node.js' console.log asynchronous?
I imagine it's implemented similar in some of the browsers.
I'm not familiar with node.js, however it's typically not a good thing to log anything except critical errors in a production environment. Unless node.js offers a logging utility like log4j, you should look at something like log4js (haven't used, just first google response)
I have a huge Web App that's switching from a HTML-rendered-on-the-server-and-pushed-to-the-client approach to a let-the-client-decide-how-to-render-the-data-the-server-sends, which means the performance on the client mattered in the past, but it's critica now. So I'm wondering if in the current state of affairs it's possible to profile Web apps and extract the same data (like call stacks, "threads", event handlers, number of calls to certain functions, etc) we use for server side perf.
I know every browser implements some of these functionalities to some extent (IE dev tools has an embedded profiler, so does Firefox [with Firebug], and Google Chrome has Speed Tracer), but I was wondering if it'd be possible to get, for example, stack traces of sessions. Is it advisable to instrument the code and have a knob to turn on/off the instrumentation? Or it's simply not that useful to go that level in analyzing JavaScript performance?
Fireunit is decent and YUI also provides a profiler, but neither provide stack traces or call frames. Unfortunately, there aren't many JS profiling tools out right now. And none of them are particularly great.
I think it's very important to go to a high level of performance analysis, especially considering the user will deal with the JS app 90%+ of the time directly.
Reading through this question on multi-threaded javascript, I was wondering if there would be any security implications in allowing javascript to spawn mutliple threads. For example, would there be a risk of a malicious script repeatedly spawning thread after thread in an attempt to overwhelm the operating system or interpreter and trigger entrance into "undefined behavior land", or is it pretty much a non-issue? Any other ways in which an attack might exploit a hypothetical implementation of javascript that supports threads that a non-threading implementation would be immune to?
Update: Note that locking up a browser isn't the same as creating an undefined behavior exploit.
No, multiple threads would not add extra security problems in a perfect implementation. Threaded javascript would add complexity to the javascript interpreter which makes it more likely to have an exploitable bug. But threads alone are not going to add any security issues.
Threads are not present in javascript because "Threads Suck" - read more from the language designer (http://weblogs.mozillazine.org/roadmap/archives/2007/02/threads_suck.html)
Well, you can already lock up a browser and seriously slow down a system with badly-behaved JS. Enlightened browsers have implemented checks for this sort of thing, and will stop it before it gets out of hand.
I would tend to assume that threads would be dealt with in a similar manner.
Perhaps you could explain what you mean by "undefined behavior" then? An interpreter that allowed untrusted script to directly control the number of OS-native threads being run would be incredibly naive - i don't know how Gears runs things, but since the API is centered around Workers in WorkerPools, i would be very surprised if they aren't limiting the total number of native threads in use to some very low number.
Well I think that the only major example of multi-threaded javascript is Google's chrome (WOULD THEY RELEASE IT ALREADY JEEZ) and if I understand it the javascript will only one process per tab, so unless it started spawning tabs (popups) I would assume this would be a null issue, but I think that Google has that under wraps anyway, the are running all the javascript in a sandbox.
Again, we need to make a distinction between 1) multithreaded support in the language (which I don't think is seriously being discussed as something that will happen) and 2) usage of multiple threads in the JavaScript engine/interpreter in the browser.
For #2, I can't see how this can really add any possible security concerns to the engine/interpreter, unless there are flaws in the implementation.