AIR has a ways to go as a desktop application platform

Imagine a simple file-search desktop application.  A user could type in a search string and press a button to start the search.  The application would then recurse the directories on the user's computer searching for files whose names contained that string.  Nothing complex, not even a cancel-search button or progress bar.

Now while the application recurses sub-directories, we want the user-interface to be responsive so the user (and the operating system) don't think the application has crashed.  In .NET and JAVA, this is as simple as putting the file-search and user-interface on different threads.

In AIR this is simply not possible. Using the file-system search as an example, Adobe provides a getDirectoryListingAsync() function, you call it and then listen for a FileListEvent.  Since our simple application needs to recurse sub-directories in search of matching files, it will need to parse the returned file-system items and venture into the returned directories calling getDirectoryListingAsync on those as well and so on.  Adobe also provides the getDirectoryListing() function which if used will yield much the same outcome through synchronously and without the need for an event listener.

A few folks have asserted that getDirectoryListingAsync() does in fact run on a separate thread.  If that's true then great, the problem is the FileListEvents are still handled on the UI thread, and when recursing through lower-level directories, there are quite a few FileListEvents.  So sadly, when these methods are used to access the file-system in AIR, the UI becomes sluggish and unresponsive, especially when recursing from lower directories.  AIR is simply doing too much work on one thread and doesn't have the resources to paint the UI.

There are a lot of smart folks (another smart person) who've come up with work-arounds for this limitation, most attacks boil down to this:

Split up your process in some way and call sections of your newly split-up process in chunks on each frame, allowing AIR to paint the UI.

That sure is a lot of work.

If we had threads, we could write this application via two simple concurrent processes.  Recursing sub-directories is easy to do, and so is responding to user gestures on the UI.  The sub-directory searching process could even raise events that we'd listen for on the UI thread letting the user know interesting bits like: progress, files found, directories searched, etc.  The directory search could even be a simple, synchronous process (hey, its running on its own thread).

It is certainly worth noting that concurrent programming is hard (if you don't think so, you're either a badass or are new to it) and introduces subtle and confounding bugs.  The pay-offs are huge but you run a risk as well (Microsoft charted a great middle course with BackgroundWorker).  People are always clamoring for features in AIR, so here's my vote.  Give me threads.

Edit: I've put up an Ersatz threading example which attempts the attack outlined above.