Going Async
In a world overflowing with data and networks in which information doubles in size seemingly every day, programming has had to change, banishing conventional procedural programming for asynchronously written apps able to handle information whenever it arrives without causing problems. Jono Bacon and Stuart ‘Aq’ Langridge explore how important async is, and why it is just so confusing to so many coders.
Remember, we are just the very start of the conversation! What do you think? Is async really that hard? Is it really that important? What is your experience with going async? Share your thoughts in the shot comments below…
18 Comments to “Going Async”
Leave a Reply
I did hit this problem when I started working with AJAX. I had a habit of trying to use data before an async call had time to complete, and I hadn’t got the hang of when a callback was being called.
In web applications, it’s definitely that important as it prevents pages having to be reloaded every time a small part of the content is changed, which isn’t good for user experience. I primarily work with a web app that’s almost completely syncronous and some parts of it are dreadful to use. However, it’s not that hard to go async as there are plenty of javascript libraries to make writing the code pretty straightfoward. Javascript’s use of anonymous functions and object notation also allows the code to be written more like procedural code would be, so there’s less of a paradigm shift.
The old way to do this was to use threads. So each activity was handled by a separate thread, but this has the downside of needing to be careful on the overwrite problem. This is where 2 (or more) threads attempt to update the same value. To avoid this programmers introduced locking.
The async model is to break every operation down in to a transition. The single thread runs on the event queue and processes events in atomic manner. So processing some input may kick off other input output, database reads etc that will generate further events on completion. The down side of this is you have to remember where you were when that event happens and therefore what happens next. In a procedural environment this is implicate in terms of where in the program we are.
Doing asynchronous programming in a language with mutable data is a major problem because one thread can over-write data that another thread depends on. Locks can solve this problem, but they can also be a problem because of deadlocks and cyclic dependencies. The only clean way to do asynchronous programming is to use a language where everything is imitable, with side effects offered in a controlled way. I cannot see every programmer switching to a language like Haskell any time soon.
I’ve had horrendous experiences with Boost.Asio; first trying to get it to handle named pipe IPC in Windows, and then just simple SSL network connections. Both attempts failed miserably, and I wound up using the native Win32 async APIs, which are annoying and non-OO, but they do actually work.
I don’t think the concepts are too difficult. We (users of C++, anyway) simply need better tools. Twisted is a pretty good example in Python, but it has a few issues of its own.
The language support is definitely coming. Google’s Go language is built with this built in, using goroutines and channels for communication [1]. And Apple have made a C extension to go with their Grand Central Dispatch/libdispatch code [2] which also makes it easy to hand off tasks to other threads and keep the GUI alive. (And libdispatch should be coming to Linux [3]).
All this should make it a lot easy for us programmers
[1] – http://golang.org/doc/effective_go.html#concurrency
[2] http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/12 and a code example in http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/13
[3] – http://arstechnica.com/open-source/news/2009/09/apple-opens-gcd-challenges-impede-adoption-on-linux.ars
The picture… WTF?!
Instead of just looking at this from the programming perspective, what about systems? The whole APT repository system is predicated on synchronous access to the repos. While Linux and connectedness may seem intertwined, that should not be considered to always be the case.
For those operating boxes that are not net connected (I have a PowerPC that is quite the Karmic island) there are DVD snapshots available to make asynchronous access possible. Those do age over time. Those same snapshots totally suck when trying to apply security updates due to their very nature as snapshot. There is no clear work-around within the toolchain yet for this, alas.
Basically I’ve been fussing over things myself to see how to break the synchronous connection your vanilla APT rigging looks for. Things like apt-zip try to take that client-server interaction in an asynchronous direction but lack the functionality to handle an “apt-get update” even though it grabs packages nicely. I have a kludge that I use on a connected machine to make the “apt-get update” action happen across the particular machine’s chasm of asynchronicity but it is nasty enough to make a proper developer vomit. Still, once that bit of nastiness is in play I can then use Synaptic’s download script tool in the way it seems to have been intended initially.
Between outages out my way and more drastic events elsewhere, synchronous access for various Linux subsystems is a luxury becoming more and more pricey. If memory serves, I threw into the mix of a blueprint for Lucid under NGO team about this whole synchronous/asynchronous question. I can conceptualize it…I just am not skilled at coding a fix…
I’ve been using Twisted (and asynccore) for a couple of years now, and I recommend it strongly for applications that need to do any sort of communications while also doing “something else” (including more communications). For example, I have an application that opens dozens of client connections to other servers, while also operating multiple server ports with multiple protocols, while also simultaneously running complex background applications logic … and it was easy!
What wasn’t easy was figuring out how to get starting doing this in the first place. The documentation that I was able to find for Twisted or asynccore (they operate on similar principles) was either oriented towards very simple examples, or it assumed you already knew everything. There wasn’t anything to really guide me when going from the “hello world” level to larger real world applications. Now that I know what I’m doing, it’s all “obvious” to me, but it certainly wasn’t obvious when I was learning how to do it. That is how I found things in Python. I don’t know how other languages compare (not as well, from what I’ve seen).
Once you’ve climbed that hill however, it isn’t any harder to write software to be asynchronous than it is to make it “blocking”. You can achieve the same end using threading, but usually only with a lot more effort because you have to deal with locking and semaphores and all the bugs that accompany getting that right.
I’ve been through the Twisted documentation as well and I completely agree with you. Do you have any suggestions on how to bridge the “where do I go from here” gap?
There’s one problem with async I tend to stumble upon – debugging apps you haven’t written. I once tried to debug something which called a few chained async functions and the problem was to get the call tree right (of course other functions while running when the async one were being called) – it’s a lot harder than debugging an “usual” app…
Yes. This is because we don’t have tools to help, I think.
I think it depends on what sort of language constructs you’re using.
While the classic way of using Twisted with lots of little callbacks attached to deferred objects can be quite difficult to debug, if you use it’s newer generator based inlineCallbacks infrastructure things can be a lot easier.
If your inlineCallbacks based function fails with an exception, the resulting failure captures the traceback. Similarly if your function yields a deferred that eventually fails, the failure gets converted to an exception raised with the failure’s traceback.
Combine these two properties, and it becomes quite easy to trace the original cause of a failure in complicated async code, similar to how you’d debug an unexpected exception in synchronous code.
inlineCallbacks are mighty genius. That’s exactly what I had in mind when I talked about how tools need to improve to help people grasp async programming; inlineCallbacks, to me, seems like an evolution in that direction. It is sorta-kinda a cheat in that it lets you go async while still thinking sync-ly. I can’t decide whether that’s a good thing or not. But I like it anyway.
Good shot. I do really hope that development, particularly of desktop GUI apps start being written this way by default.
I mostly write my little GUI apps with POE and Gtk+ event loop (POE is a Perl async library a /bit/ like Python’s twisted). GUI apps locking up when they’re blocking on something really isn’t acceptable in this day and age!
I listened to this shot, then received the most awesome email ever. It started out by telling me that the author had stayed up late that night because he had worked out that that meant I’d receive it at a reasonable time.
I felt like I should tell him to think about how email is asynchronous and how I didn’t even see the email until about 36 hours after he had sent it.
I’m not a real programmer as such, my day job is as a network and security consultant. Something that has been causing me to think a lot is how well the Internet and networks in general will cope with the ever increasing scale problem. This aligns well with the proposition you propose. In particular is the fact that much of our connections to networks will be transient and casual – wireless networks and mobile devices being the most obvious examples.
There are others that have been thinking about this. Two research groups that have struck me I heartily recommend people look at.
Van Jacobson, one of foundational designer of the TCP/IP stacks has been heading research at PARC on Content-Centric Network. He proposes a level of abstraction that allows information to get where it needs to quite distinct from the underlying network.
The other one I find intriguing is the proposition of the Pouzin Society. Similar but different they also propose the idea that networking should be analogous to Inter Process Communication (IPC).
To be honest, I don’t claim to have absorbed even a tenth of what they have to say, and they may well have it all wrong. But definitely Google for the above and take the time to think differently of how networking could be – or even needs to be.
I see the async problem at least once a day when I try to print to a network printer from ubuntu. If the printer is sleeping, the dialog greys out until it comes back online.
It’d be nice for the async philosophy/coding style to integrate down to the simplest utilities.
[...] I set out with was to download a file without freezing the GUI. This was somewhat inspired from a recent Shot Of Jaq shot that we did on async programming, and I used this app as a good example to play with. [...]