A block formatting context is a box that satisfies at least one of the following:
* the value of “float” is not “none”, * the used value of “overflow” is not “visible”, * the value of “display” is “table-cell”, “table-caption”, or “inline-block”, * the value of “position” is neither “static” nor “relative”.
A concurrent program is one with multiple threads of control. Each thread of control has effects on the world, and those threads are interleaved in some arbitrary way by the scheduler. We say that a concurrent programming language is non-deterministic, because the total effect of the program may depend on the particular interleaving at runtime. The programmer has the tricky task of controlling this non-determinism using synchronisation, to make sure that the program ends up doing what it was supposed to do regardless of the scheduling order. And that’s no mean feat, because there’s no reasonable way to test that you have covered all the cases. This is regardless of what synchronisation technology you’re using: yes, STM is better than locks, and message passing has its advantages, but all of these are just ways to communicate between threads in a non-deterministic language.
A parallel program, on the other hand, is one that merely runs on multiple processors, with the goal of hopefully running faster than it would on a single CPU.
So where did this dangerous assumption that Parallelism == Concurrency come from? It’s a natural consequence of languages with side-effects: when your language has side-effects everywhere, then any time you try to do more than one thing at a time you essentially have non-determinism caused by the interleaving of the effects from each operation. So in side-effecty languages, the only way to get parallelism is concurrency; it’s therefore not surprising that we often see the two conflated.
However, in a side-effect-free language, you are free to run different parts of the program at the same time without observing any difference in the result. This is one reason that our salvation lies in programming languages with controlled side-effects. The way forward for those side-effecty languages is to start being more explicit about the effects, so that the effect-free parts can be identified and exploited.
Internet Explorer Surprisingly, it’s pretty easy to play a mp3 on IE, even on version 6. The little known bgsound element does it for you, no questions asked. On IE9, with all the amazing HTML5 support, you can also use an audio tag, but IE9 misreports that it can play mp4 files when it can’t.
Safari Can play mp3′s and m4a’s just fine with the audio tag, but behold: On Windows, if QuickTime is not installed also, not only will it not play any codecs, but the audio tag simply doesn’t exist, and the Audio object in JavaScript doesn’t either.
Firefox Has support since 3.5, but it will only play OGG and WAVE files. Go figure.
Chrome Has broad support and will play most stuff thrown at it. Also, no cross-platform differences.
Mobile devices You can’t auto-play sounds, so forget about playing sounds as part of the UI now. On some devices (namely recent iOS devices) you can play sounds as a result of a direct user interaction (e.g. tap). It’s out of the scope of this article really.
When HTML5 is there, do this:
First, you need mp3, mp4 and ogg versions of your sound.
if("Audio" in window){ var a = new Audio(); if(!!(a.canPlayType && a.canPlayType('audio/ogg; codecs="vorbis"').replace(/no/, ''))) a.src = "/sounds/ping.ogg"; else if(!!(a.canPlayType && a.canPlayType('audio/mpeg;').replace(/no/, ''))) a.src = "/sounds/ping.mp3"; else if(!!(a.canPlayType && a.canPlayType('audio/mp4; codecs="mp4a.40.2"').replace(/no/, ''))) a.src = "/sounds/ping.m4a"; else a.src = "/sounds/ping.mp3";
Basically, the code tries to use QuickTime, Windows Media and RealPlayer to play back the sound. You could add a Flash failover, but for that you need specially crafted Flash files, and then you get yourself into the whole Flash blocker madness. Avoid.
Use Symbolic Links to Unlock Dropbox’s Potential Mklink is a command line command short for “make link.” It’s used to create symbolic or hard links, which allow you to connect files and folder. It’s sort of like creating shortcuts, except that they’re handled at the operating system level, so they work with any program. You can, for instance, use mklink to fool Steam into thinking that a game on a different hard drive is actually in your Steam games folder. You can link files on a single computer, or across a local network. You cannot, however, link files across the internet. 1. Find the directory containing your Firefox profile. A default installation places this folder in %APPDATA%\Mozilla\Firefox 2. Copy that Firefox directory into your Dropbox folder. 3. Delete the original Firefox folder. 4. Use Mklink to create a hardlink between the new and original Firefox folders, If your Dropbox folder is in C:/ you can use the following command:
Store All Your Passwords with Keypass That’s where KeePass comes in. KeePass is a free, open source password safe. It allows you to generate a unique, totally random password for every site or service you use, while only requiring you to remember a single master passphrase. Whenever you attempt to log into a service, KeePass asks for your master passphrase, then automatically enters the appropriate password from your safe.
Use Dropbox to manage BitTorrent First, make sure you have a BitTorrent client capable of automatically loading .torrent files from a folder. All the big ones are capable of this, including uTorrent, Vuze, and the standard BitTorrent client. Next, set it up to monitor your DropBox, or a folder in your DropBox (My Documents/My Dropbox/Torrents for instance) and automatically open any .torrent file added to that folder.
Now, if you see a file you want to grab, just download the .torrent file to your Dropbox/Torrents folder, and your home PC will start the download as soon as DropBox syncs. It’s as simple as that.
So the largest waste with current programming technologies comes from waiting for I/O to complete. There are several ways in which one can deal with the performance impact (from Sam Rushing):
* synchronous: you handle one request at a time, each in turn. pros: simple cons: any one request can hold up all the other requests * fork a new process: you start a new process to handle each request. pros: easy cons: does not scale well, hundreds of connections means hundreds of processes. fork() is the Unix programmer’s hammer. Because it’s available, every problem looks like a nail. It’s usually overkill * threads: start a new thread to handle each request. pros: easy, and kinder to the kernel than using fork, since threads usually have much less overhead cons: your machine may not have threads, and threaded programming can get very complicated very fast, with worries about controlling access to shared resources. The second basis thesis is that thread-per-connection is memory-expensive: [e.g. that graph everyone showns about Apache sucking up memory compared to Nginx]
Apache is multithreaded: it spawns a thread per request (or process, it depends on the conf). You can see how that overhead eats up memory as the number of concurrent connections increases and more threads are needed to serve multiple simulataneous clients. Nginx and Node.js are not multithreaded, because threads and processes carry a heavy memory cost. They are single-threaded, but event-based. This eliminates the overhead created by thousands of threads/processes by handling many connections in a single thread.
An event loop is “an entity that handles and processes external events and converts them into callback invocations”. So I/O calls are the points at which Node.js can switch from one request to another. At an I/O call, your code saves the callback and returns control to the node.js runtime environment. The callback will be called later when the data actually is available.
Of course, on the backend, there are threads and processes for DB access and process execution. However, these are not explicitly exposed to your code, so you can’t worry about them other than by knowing that I/O interactions e.g. with the database, or with other processes will be asynchronous from the perspective of each request since the results from those threads are returned via the event loop to your code. Compared to the Apache model, there are a lot less threads and thread overhead, since threads aren’t needed for each connection; just when you absolutely positively must have something else running in parallel and even then the management is handled by Node.js.
Other than I/O calls, Node.js expects that all requests return quickly; e.g. CPU-intensive work should be split off to another process with which you can interact as with events, or by using an abstraction like WebWorkers. This (obviously) means that you can’t parallelize your code without another thread in the background with which you interact via events. Basically, all objects which emit events (e.g. are instances of EventEmitter) support asynchronous evented interaction and you can interact with blocking code in this manner e.g. using files, sockets or child processes all of which are EventEmitters in Node.js. Multicore can be done using this approach; see also: node-http-proxy.
Internal implementation
Internally, node.js relies on libev to provide the event loop, which is supplemented by libeio which uses pooled threads to provide asynchronous I/O. To learn even more, have a look at the libev documentation.