Lucee dialect: async programming?

218 views
Skip to first unread message

Sean Corfield

unread,
Apr 23, 2015, 4:44:14 PM4/23/15
to lu...@googlegroups.com
We’ve had `thread` in CFML for a long time now but it’s really only suitable for running procedural (side-effecting) code in background threads. It’s not really very good for async programming in general.

I think it would be a really nice enhancement to the Lucee dialect to fully support futures and promises.

There are several implementations out there in various languages so there are quite a few specific models to choose from.

For those not familiar, the general idea is something like this:

var a = future( some expression );
var b = future( some other expression );
var c = a.get() + b.get();

This spins off some expression and some other expression to execute in other threads, but immediately returns a reference to the "future" value. Calling get() on the future will block until the value is available (or return immediately if the expression has already completed). Calling get() multiple times will just return the computed value (it’s cached for the life of the reference).

Promises are similar but rely on other code to compute the value:

var a = promise();
var b = promise();
// maybe in another thread:
a.deliver( 42 );
// maybe in yet another thread:
b.deliver( 13 );
var c = a.get() + b.get();

Like futures, the get() call will block until the promise has a value.

Both of these allow complex operations — time-consuming ones — to be broken down and easily run concurrently while maintaining much clearer code than trying to manage a whole bunch of thread { … } statements assigning values back and forth.

Fancier features allow for completion callbacks, error callbacks, timeouts (and timeout callbacks), etc.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



Konstantinos Liakos

unread,
Apr 23, 2015, 5:04:04 PM4/23/15
to lu...@googlegroups.com
+1

Async functions is a must have. It is one of the main reasons I consider using other languages like java or node.

Andrew Dixon

unread,
Apr 23, 2015, 5:30:59 PM4/23/15
to lu...@googlegroups.com
Sean, that is the clearest, simplest explanation I have ever seen for futures and promises, and now I feel I actually understand them, I have read far longer articles in the past and was always left feeling that I still didn't really "get" what they did. Thanks so much. Also +1 for this in the Lucee dialect.

Kind regards,

Andrew
about.me
mso - Lucee - Member

--
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/ACB680DA-40A9-4CA5-9E6F-670AF5A56973%40corfield.org.
For more options, visit https://groups.google.com/d/optout.

Andrew Dixon

unread,
Apr 23, 2015, 5:34:06 PM4/23/15
to lu...@googlegroups.com

Kind regards,

Andrew
about.me
mso - Lucee - Member

Dan Kraus

unread,
Apr 23, 2015, 7:40:36 PM4/23/15
to lu...@googlegroups.com
Really great and simple explanation, Sean.

Definitely would support something like this. Very useful running fat queries or something to assemble data for reporting, or hitting some web service(s), a lot of things.

AJ Mercer

unread,
Apr 24, 2015, 12:22:48 AM4/24/15
to lu...@googlegroups.com
Does 'block' mean hold up execution of the code?

If so, then the only benefit is tidy code - not that that is a bad thing.

I think for it to be really beneficial is to have the call back functions - to go totally asynchronous, verses multi-threaded.
Wow, that would be an exciting time to be a CFML developer.


--
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/ACB680DA-40A9-4CA5-9E6F-670AF5A56973%40corfield.org.
For more options, visit https://groups.google.com/d/optout.

Sean Corfield

unread,
Apr 24, 2015, 12:33:26 AM4/24/15
to lu...@googlegroups.com
On Apr 23, 2015, at 9:22 PM, AJ Mercer <ajme...@gmail.com> wrote:
Does 'block' mean hold up execution of the code?

If so, then the only benefit is tidy code - not that that is a bad thing.

Not so. The benefit is being able to run multiple long-running pieces of code easily and concurrently. Futures are about a lot more than "tidy" code. Perhaps you have to use them to really appreciate the benefits — and we use them extensively at World Singles, in Clojure. Right now we’re "forced" to rewrite CFML to Clojure so we can easily leverage futures for concurrency. If we had futures directly in CFML, we could speed up several parts of our application without rewriting them in Clojure.

I think for it to be really beneficial is to have the call back functions - to go totally asynchronous, verses multi-threaded.

You actually need multiple threads to get truly asynchronous code (if you’re thinking of JS, things that use callbacks are asynchronous because they "reach outside" the single-threaded JS engine). And, whilst callbacks can be useful for completion notifications on futures, callbacks can also lead to unreadable spaghetti code. It’s called "callback hell" for a reason.

If you want to see what totally asynchronous code can look like without callbacks, take a look at Clojure’s core.async (based on the idea of channels and "go blocks" — like the Go language):

Adam Cameron

unread,
Apr 24, 2015, 1:18:00 AM4/24/15
to lu...@googlegroups.com


On Thursday, 23 April 2015 21:44:14 UTC+1, Sean Corfield wrote:
I think it would be a really nice enhancement to the Lucee dialect to fully support futures and promises.


I've voted for the ticket Andrew raised: https://bitbucket.org/lucee/lucee/issue/314

This is one thing that the implementation of which - if it's taken up, I mean - ought to be done via a broad audience, not behind closed doors. Not the final planning, obviously, but arriving at the general approach. There seems to be a few different ways of dealing with this out there.

Good suggestion, Sean (which I thought had already been raised actually, but seemingly not).

-- 
Adam
Reply all
Reply to author
Forward
0 new messages