Lucee dialect: async programming?

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)

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 http://about.me/andrew_dixon
mso http://www.mso.net - Lucee http://lucee.org - MemberOn 23 April 2015 at 21:44, Sean Corfield <@Sean_Corfield> wrote:

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)


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/ACB680DA-40A9-4CA5-9E6F-670AF5A56973%40corfield.org
https://groups.google.com/d/msgid/lucee/ACB680DA-40A9-4CA5-9E6F-670AF5A56973%40corfield.org?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

+1

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

I’ve added this as a “proposal” to the issue tracker:

https://bitbucket.org/lucee/lucee/issue/314/add-futures-and-promises-to-the-lucee

Kind regards,

Andrew
about.me http://about.me/andrew_dixon
mso http://www.mso.net - Lucee http://lucee.org - MemberOn 23 April 2015 at 22:30, Andrew Dixon <@Andrew_Dixon> wrote:

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 http://about.me/andrew_dixon
mso http://www.mso.net - Lucee http://lucee.org - Member

On 23 April 2015 at 21:44, Sean Corfield <@Sean_Corfield> wrote:

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)


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/ACB680DA-40A9-4CA5-9E6F-670AF5A56973%40corfield.org
https://groups.google.com/d/msgid/lucee/ACB680DA-40A9-4CA5-9E6F-670AF5A56973%40corfield.org?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

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).On Thursday, 23 April 2015 21:44:14 UTC+1, Sean Corfield wrote:


Adam

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):

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)On Apr 23, 2015, at 9:22 PM, AJ Mercer <@AJ_Mercer> 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.

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.On 24 April 2015 at 04:44, Sean Corfield <@Sean_Corfield> wrote:

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)


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/ACB680DA-40A9-4CA5-9E6F-670AF5A56973%40corfield.org
https://groups.google.com/d/msgid/lucee/ACB680DA-40A9-4CA5-9E6F-670AF5A56973%40corfield.org?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

AJ Mercer
<webonix:net strength=“Industrial” /> http://webonix.net | <webonix:org
community=“Open” /> http://webonix.org
http://twitter.com/webonix