Comments on: Minimizing Code Paths in Asychronous Code

By: Bill Wilson

Bill Wilson — Thu, 12 Jun 2008 12:20:38 +0000

I made a minor addition to the Memoize function to accept a variable number of arguments. I used this function to completely rewrite a series of AJAX calls. The results were quite nice. Thanks for the idea.

// Memoize function // k must have a signature k(data,id,...); //Additional arguments are passed to the program. function asyncMemoize (f) { var cache = {}; return function (x, k) { var v = cache[x]; var args = Array.prototype.slice.call(arguments); args[1] = x; if (v) { args[0] = v; setTimeout(function() { k.apply(null,args); }, 10); } else { f(x, function (v) { cache[x] = v; args[0] = v; k.apply(null,args); }); } } }

By: Paul Houle

Paul Houle — Fri, 02 May 2008 17:13:03 +0000

I’ve spent a lot of time in the last year working in GWT and Silverlight 2, both of which involve programming in a strictly typed OO language that uses XHR for communications: so you have the same issues with concurrency that you talk about in Javascript. I’ve been writing a series articles of patterns about how to write correct RIA’s despite the fact that callbacks can run in a random order:

http://gen5.info/q/category/asynchronous-communications/

By: oliver

oliver — Tue, 22 Apr 2008 18:00:53 +0000

The modified function actually does guarantee the order of execution: that the code that follows the call to requestProductDetails will always execute prior to the invocation of the continuation parameter.

Making each part of program not rely on the order of execution may seem like a good thing, but it increases the number of required test cases exponentially, if nothing else. Some indeterminacy is inherent in distributed processing; the rest can be determinized.

By: Chii

Chii — Tue, 22 Apr 2008 14:20:20 +0000

while it is a good thing ™ to make sure that code works the way the programmer expects – that the async callback gets executed after the next statement, one should remember that the reality of async is that you cannot guarentee order of execution, and thus, should instead modify the design of the program to not have to rely on the order of execution. There is no other way to fix this “problem”.

By: Bret

Bret — Mon, 21 Apr 2008 04:03:07 +0000

The inside of the function doesn’t have to look complex if you abstract out the gunk:

[blockcode]
requestProductDetails = asyncMemoize(function (id, k) {
ajax.get(’/product/’+id, k);
});
[/blockcode]

Here’s a definition of asyncMemoize. (My Javascript is rusty, so forgive any bad grammar.)

[blockcode]
function asyncMemoize (f) {
var cache = {};
return function (x, k) {
var v = cache[x];
if (v) {
setTimeout(function() { k(v); }, 1);
}
else {
f(x, function (v) {
cache[x] = v;
k(v);
});
}
}
}
[/blockcode]

(A better definition could use varargs, but whatever.)

I agree that a given function should always or never invoke the callback asynchronously. Not because I want to minimize code paths, but because that’s part of the interface. Your first version of requestProductDetails essentially has undefined behavior!

I would go further and suggest a naming convention, either as part of the function name or the name of the continuation argument, that indicates that it’s asynchronous. (I’ve been steeped in Objective-C for the last year, and I’m loving the Smalltalk-style descriptive method/argument naming.)