Languages of the real and artificial - Latest Comments in Minimizing Code Paths in Asychronous Code

Re: Minimizing Code Paths in Asychronous Code

Bill Wilson — Thu, 12 Jun 2008 08: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); }); } } }

Re: Minimizing Code Paths in Asychronous Code

Paul Houle — Fri, 02 May 2008 13: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/

Re: Minimizing Code Paths in Asychronous Code

oliver — Tue, 22 Apr 2008 14: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.

Re: Minimizing Code Paths in Asychronous Code

Chii — Tue, 22 Apr 2008 10:20:20 -0000

while it is a good thing (tm) 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".

Re: Minimizing Code Paths in Asychronous Code

Bret — Mon, 21 Apr 2008 00: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.)