Async, Futures and Promises
Jon Clausen
public void function process_stuff(event,prc){
//Anything up to a closing semicolon is executed asynchronously
async{
var stuff = getModel('Stuff').findAll();
//get other stuff
promise(
//scope or null
prc,
//variable name, either scope or, if scope is null, it becomes a local variable
'moreStuff',
//async event to ensure
getModel('OtherStuff').findAll()
);
}
//await example - would begin blocking again until the next action is completed
await(
prc.moreStuff,
function(){
//do stuff with moreStuff
});
//future() usage example, would block function execution until the promise arguments are met
event.setValue(‘doubleStuff’,{future(stuff),future(prc.moreStuff)});
}
The idea with the future() method as a function argument would be to keep it non-blocking until the argument, itself, was called called explicitly. So, if we didn’t want to deal with await, we could just have the future() serve as a pseudo-await() like so:
doStuffWithMoreStuff(future(prc.morestuff)) - which would, in effect, do the same thing as the await() block above.
I’m not a language development expert like many here, so this is a very uninformed poof-of-concept. There would also have to be a server-size timeout mechanism to handle awaits and futures that never materialize - as you could lock up an entire request, and possibly a server, with an incomplete callback or unfulfilled promise.
Anyway, I wanted to open the topic up to discussion, as I think it’s an important one for the future of Lucee.
Jon
Andrew Dixon
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/etPan.54ff3e57.54fc792c.f65b%40jonclausen-mbp.local.
For more options, visit https://groups.google.com/d/optout.
Jon Clausen
Sure. Sorry, meant “Adam”, typed “Andrew”… Oops.
The fundamental issue with threads is that they require an explicit join at some point. A future() or await() would accomplish somewhat the same thing, but the join mechanism would would be blocking on the explicit call for the promised variable. Plus, CFThread is, IMHO unnecessarily verbose for what it accomplishes. Let’s take my pseudo code in cfthread:
public void function process_stuff(event,prc){
//I have to implicitly create the thread, and have to scope it afterward
thread action="run" name="stuff"{
thread.returnValue=getModel('Stuff').findAll();
}
//Ditto
thread action="run" name="otherstuff"{
thread.returnValue=getModel('OtherStuff').findAll();
}
// here's where I wait for them all to come together again,
// everything is blocked from here on out
// plus I have to be very verbose and re-scope
thread action="join" thread="stuff,otherstuff";
now I re-scope the variables *sigh*
var stuff = cfthread.stuff;
prc.otherstuff = cfthread.otherstuff;
//do more stuff with stuff *sigh*
for(thing in moreStuff){
//do things to stuff
}
event.setValue('doubleStuff',{stuff,prc.moreStuff})
}
If you go back to my original example, blocking for “stuff” doesn’t happen until the variable is explicitly called in event.setValue(), while blocking does occur for prc.moreStuff in the await tag, I could also make promises to be passed as futures to the other arguments or even pass futures in to scopes.
Let’s take this one step further. The server has control of the request (as in cfflush). Let’s say we were to add a function, ( e.g. - toDocumentObject(varName,future,[exclude]) ) which would automatically deliver a JSON object before the document was closed. Rendering could begin and our request would appear to have very low latency, but something like AngularJS could pick up the object and use it tor render data once it has been added to the document. For something like data from a web service, this could really speed things up, without slowing things down waiting for the third-party request to process.
toDocumentObject(myStuff,future(stuff),[{"private":true}]);
This would allow the developer to block for necessary data but use a single request, rather than a separate AJAX call to pull the JS variables needed to render the non-essentials.
CFThread, IMHO, is cumbersome and requires to begin blocking far to early.
Jon
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG1WijXain_PBHg8f%3DeB7RCKbCcUbJ7CsWkGrWyMfWej2JQPdA%40mail.gmail.com.
Jesse Shaffer
process_stuff(event) {
// this is more similar to the way JS promises appear to work.
// the benefit is, you do not have to block process_stuff from returning - it is truely async.
var promise = runAsync(function() {
return getModel("Stuff").findAll();
}) // promise returned from runAsync
// if the async function is complete at the time the handler is attached, the handler is immediately run. otherwise it is run as a callback on the async function's completion.
.onSuccess(function(returnValue) {
event.setValue("stuff", returnValue);
// then maybe:
// event.continue();
})
.onFailure(function() {
// handle exception
})
.onCompletion(function() {
// do something whether it is successful or failed
});
// or more fluently (although it doesnt look right if you run something async and do not attach any handlers...)
var promise = when(function() {}) // when() returns a promise
.succeeds(function(){})
.fails(function() {})
.completes(function() {})
;
// then, if you absolutely must block until the promise is done processing:
promise.block();
}Jesse Shaffer
Would you get a promise for an async block without blocking on its return?
Jon Clausen
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/d18d2857-119a-4f2f-b1e7-69578281d6ba%40googlegroups.com.
Adam Cameron
On Tuesday, 10 March 2015 18:56:29 UTC, Jon Clausen wrote:
Since I brought it up, Andrew challenged me to start a separate thread for this, here it is. :)