Asynchronous I/O in Programming (and Chickens)

Gloria, you're always on the run now...

Today we're looking at how input and output operations can be handled on a computer. But because I spend all my days sat at a laptop I will instead use a chicken to explain this process. Because why not?

See our chicken up there ↑, let's call her Gloria. Gloria is hungry and is looking for something to eat. She finds a tasty worm and gobbles it up. Now would Gloria then come to a complete standstill until said worm has worked its way through her little chicken body? Oh no! That could take ages and Gloria has much to do with her day. Maybe laying the odd egg or two, doing some laundry for the little chicks, I don't know? But the point is she just gets on with chicken related things, and later on when her little worm meal has been digested she's all ready to poop it out (come on, surely you'd realised by now this was not going to be a high-brow blog post!).

This is an example of asynchronous input/output (I/O) processing, or non-blocking I/O, as Gloria can do many other things whilst her worm meal is being 'processed'. The alternative approach would be called, unsurprisingly, synchronous I/O, or blocking I/O, which would prohibit Gloria from doing anything at all after chowing down on that tasty worm until it had been fully processed and returned to the grass where it first came from (all be it in a little chicken poop form). This approach might be OK in some situations, but it's not the right thing for Gloria! What if the Colonel turns up at the farm and Gloria needs to hide behind a tree or something? She'd be rooted to the spot whilst her little chicken tummy digests the worm, the Colonel spots an easy picking and before you can say "Bargain Bucket", she's being served up in gravy and enjoyed with a hot butter biscuit.

Poor Gloria.

Chickens and computers have an awful lot in common. Which is something I never imagined myself typing at any time but honestly they do! Just like Gloria and her digestive system, input and output operations on a computer can be really slow, especially when compared to the processing of data. Take for example an I/O device like a hard drive seeking a track to read or write, or something that has to physically move. That request for a particular operation could take ten milliseconds to perform, which doesn't sound like a long time but when compared to the simple switching of an electric current in a one gigahertz processor it's snail pace. In fact, in that time the processor could've performed ten million instruction-processing cycles! That's a lotta worms!

Leaving Gloria behind now and returning fully to the world of computing, let's clarify asynchronous and synchronous I/O in practice. As we know, with asynchronous I/O processing your code continues executing after one element sends a particular message/calls a function/whatever. Whereas with synchronous I/O your code sends a message/calls a function/whatever but then it is blocked until an answer/response/whatever arrives. This could be seconds, minutes, hours, days.......you get the idea!

But you likely want your asynchronous I/O request to perform a certain task after it has received the answer/response/whatever, right? So to do this we can include a callback function which will only execute when the answer/response to the message/request/function/whatever arrives. This could be seconds, minutes, hours, days......

Here we have a button which after it has been clicked will execute the callback function on line 2. The rest of your code can carry on and do what it wants to do, but after you click that button the callback function will come into play.

It is also possible to use a timeout function in your asynchronous request, this would call a function or execute some code after a specified delay. In JavaScript we could use 'setTimeout', like this...

...which will display 'Boom!' after 2000 milliseconds have passed. With JavaScript built into browsers this could be a useful tool to display a pop-up to a webpage visitor after they have been browsing the page for a certain amount of time.

Now, anyone fancy KFC?

Functional JavaScript: Scope and Hoisting

JavaScript: putting the fun in functional since 1995!

With so much function going down it's hardly surprising that JavaScript is a functional language.

But what do we mean by that?

Well a function is kinda like an independent mini-program within a program. And so any variables you create inside a function only have meaning inside that function. When the function finishes, the variables disappear - as in they will not be carried over into subsequent functions. This is actually a really good thing as a JavaScript program could have hundreds or thousands of variables and would become very difficult to keep track of if they all carried over into the other functions. It means we can re-use variable names within other functions and it won't cause problems elsewhere. These variables are known as local variables.

There's also another type of variable known as a global variable. Unsurprisingly these global variables are defined at the main script level and are available to use inside each function.

The concept of local vs global variables is referred to as scope.

Slightly confusingly, in JavaScript a variable can used before it's been declared. This is because JavaScript moves all declarations to the top of the current function - this is called hoisting.

Hoisting is often an overlooked area of JavaScript, and just because something can be done doesn't mean it necessarily should. And, indeed, the example above will return an error. This is because only the declaration (var y), not the initialization (= 7) is hoisted to the top. So you could put var y lower in the script, but you can't initialize it with, in this case = 7, and expect a result.

And really, for anyone reading your code surely it would be better to declare your variables before calling them? And since this is how JavaScript interprets the code (after it has 'hoisted' the variable) then it's always a better rule to follow!