Skip to main content
Ben Nadel at cf.Objective() 2009 (Minneapolis, MN) with: Luis Majano
Ben Nadel at cf.Objective() 2009 (Minneapolis, MN) with: Luis Majano ( @lmajano )

CFThread Attributes Are Passed By Reference - Not By Deep Copy - In Lucee

Published in Comments (6)

When Adobe ColdFusion first introduced the cfthread tag, a lot of us stumbled over the fact that attributes are passed by deep-copy into the cfthread body. This was done by design in order to help prevent developers from having to worry about accessing and mutating shared state. Which, to be fair, is a very valid concern (though, one that we need to side-step all the time). I just assumed that Lucee exhibited the same behavior. But, this morning, I woke up to find a Tweet from Brad Wood stating that Lucee passed cfthread attributes by reference. Given the hard departure from the previous behavior, I wanted to see this for myself.

Testing this cfthread behavior is quite easy. All we have to do is:

  1. Create an Struct.
  2. Pass the struct into a cfthread tag via an attribute.
  3. Mutate the struct inside the cfthread body.
  4. Check to see if the mutation applied to the original struct.

NOTE: We have to use a Struct for this experiment - not an Array - because Arrays are always passed by value in Adobe ColdFusion. As such, the cfthread tag will always receive a "local copy" of the top-level Array structure in Adobe ColdFusion.

If we can see the mutation in the original struct, it means that the cfthread body received the struct by reference; and that it acted directly upon the original struct. And, if we can't see the mutation, it means that the cfthread body received its own, isolated, local copy of the struct:


	public void function testThread() {

		var localValues = { localKey: "from local" };

		// In both Adobe ColdFusion and Lucee CFML, the CFThread body cannot reference
		// the "local" scope of the parent context. As such, we have to pass the local
		// reference into the CFThread body as an Attribute. However, in Adobe
		// ColdFusion, this reference is passed by DEEP COPY. And, in Lucee, this
		// reference is passed BY REFERENCE.
			name = "ThreadyMcThreadFace"
			values = localValues

			// In Lucee, this is mutating the SHARED struct.
			// In Adobe, this is mutating a THREAD-LOCAL copy.
			values.threadKey = "from thread";



		// Let's see how / if the function-local copy was mutated.
		if ( server.keyExists( "lucee" ) ) {

				label = "Lucee #server.lucee.version#",
				var = localValues

		} else {

				label = "Adobe #server.coldfusion.productVersion#",
				var = localValues



	// ------------------------------------------------------------------------------- //
	// ------------------------------------------------------------------------------- //



As you can see, in the Function body, we are declaring an Struct with one key. Then, we pass the struct into the cfthread tag and attempt to set a second key. We then block-and-join the thread (in order to make sure it executed) and inspect the struct contents.

If we run this ColdFusion code in both Adobe ColdFusion 2018 and Lucee CFML 5.3, we get the following output (shows both results):

CFThread attributes are passed by value in Adobe ColdFusion and by reference in Lucee CFML.

As you can see, in Adobe ColdFusion, the struct is passed by value, giving the cfthread tag its own local copy work with. And, in Lucee CFML, the struct is passed by reference, which means that the Lucee cfthread works directly on the original struct reference.

This is great from a performance standpoint since Lucee doesn't have to deep-copy the data-structures going into a cfthread. But, to be clear, it does put the burden of managing shared memory space on the developer. This is a non-trivial problem, which is why Adobe went the route that they did.

That said, with the number of asynchronous processing options that we now have available in Lucee CFML, it makes sense that the controls around shared memory access are defined explicitly by the developer. The language itself can't solve most of the asynchronous access problems that we're bound to run into. As such, it is crucial that we [engineers] develop a strong sense of what is and is not OK to do with asynchronous control-flows in Lucee CFML.

Want to use code from this post? Check out the license.

Reader Comments


This kind of defeats the point of having thread attributes. I mean I thought the whole point of these attributes, was to sandbox each thread and protect it from interference from the outside environment.

Anyway. Definitely good to know, although, it seems that gap between ACF & Lucee, in terms of compatibility, keeps widening. Not good news, especially when many of my projects require cross compatibility.



It's a really good point. If nothing else, there's the "breaking change" aspect of it that I haven't seem really documented. At least, not that I can remember coming across.

My assumption is that since things like runAsync() and all the parallel iteration features (ex, array.each( closure, true )) don't provide any sandboxing, then at least this direction is "more consistent" across all the async features.

But, you are 100% correct -- you do lose that "sandbox", at least to some degree.


Ben. Yes. I can see why you might have it in other 'asynchronous' routines, but traditionally, cfthread has had sandbox integrity.

I would almost say this is bordering on a 'bug', but because it has been done deliberately to match the other asynchronous features, then, clearly it isn't a 'bug'.

It would be interesting to know, if Lucee, displayed this kind of behavior, for cfthread, in previous versions?


I might put in a feature request for an option to retain cfthread's sandbox behaviour, using something like:

<cfthread deepCopy="true">...

By default, it could be set to 'false' to maintain Lucee's current behaviour.



I mean, that's a really good idea. With other things, I'm pretty sure that Lucee has a setting where you can "enable" the Adobe ColdFusion compatible behavior in the Application.cfc. Also, I was just looking at the "syntax" differences, and I do see that you can do something like you are saying for Function-arguments:

<cfargument name="x" type="array" passby="value">

Here, the passby="value" converts Array-passing to be like Adobe ColdFusion. So, there is a precedence for "turning on" older behaviors.


That's really interesting. It's good to know there is an option to set a 'passBy' attribute for arguments to bridge the compatibility gap.

I didn't see anything similar for 'cfthread' in the Lucee Docs, but I remember you said, in a previous post, that 'cfthread' attributes act just like function arguments, so maybe the attribute works on 'cfthread'.

As I said though, the Lucee Docs don't mention anything about this.

I believe in love. I believe in compassion. I believe in human rights. I believe that we can afford to give more of these gifts to the world around us because it costs us nothing to be decent and kind and understanding. And, I want you to know that when you land on this site, you are accepted for who you are, no matter how you identify, what truths you live, or whatever kind of goofy shit makes you feel alive! Rock on with your bad self!
Ben Nadel