Asynchronous JavaScript is typically vested in separating the timing of HTTP requests from the otherwise procedural execution flow of the wrapping code. I cannot think of any other uses for making JavaScript asynchronous due to risks of potentially opening race conditions. The benefit for asynchronous JavaScript is that execution to a segment can occur while awaiting access to another body of logic, which is beneficial because when JavaScript executes it completely locks its process thread thereby opening the potential for an application collision. A race condition, coincidentally, will lock the application thread anyways unless one of the racing conditions is outside of the JavaScript interpretation.
Here is an example of asynchronous JavaScript I wrote about 6 months ago: http://prettydiff.com/api.js It is a node.js script to allow an API for my Pretty Diff application. I wanted to be able to request code sources from over a network instead of submitting code source directly. This means I needed to receive a form submission, send HTTP requests, await the responses, and the execute the Pretty Diff logic. Before making the HTTP requests asynchronous the problem I kept running into is that the response would lag behind the execution logic of the API script and this would result in an endless loop that would lock the server thread. My solution was to nest each HTTP request inside a function argument for the prior HTTP response. Instead of making the HTTP requests asynchronous this actually makes the API execution asynchronous to the procedural HTTP requests. In this case the result was fine because it was unlikely that a file would be slower to receive than to process in my application unless it is smaller than the size of its HTTP header and it prevents one thread from locking the execution of another. However, I presume this solution would lag significantly if I ever extend my application to scale beyond two file requests. The ideal solution is to write some sort of mass request algorithm that can send various requests simultaneously, catch all responses, and then performs a validation that either identifies when all of the requests have completed or supplies a defined timeout for each independent request. This is complicated because it would demand substantially increased logic over the prior solution, but must be noticeably faster than the prior solution and not lock the current processor thread. Austin Cheney, CISSP http://prettydiff.com/ On May 9, 9:57 am, Shawn Stringfield <[email protected]> wrote: > Anyone know of any great resources for learning asynchronous js? > > Sent from my iPad -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
