>I hope so, and maybe Damon will respond, but I know his blog post says
>that they have no plans to support this proof of concept code in the
>future, and they have no plans to add it to a future release. But I
>know that's probably just avoiding a 'future looking statement', so my
>guess is it will be in some future release. :)
Right now there's some threading/synchronization issues with variables, so
you have to be very careful when using the tags.
For example:
<cfthread name="Thread_1">
<cfset x = "Dan" />
</cfthread>
<cfthread name="Thread_2">
<cfset x = "Switzer" />
</cfthread>
<cfjoin thread="Thread_1" />
<cfjoin thread="Thread_2" />
The variable "x" at this point could be anything--because you don't know
which thread processed in which order. That's actually to be expected.
Where it's a problem is if you're trying to do some looping to process a
bunch of tasks asynchronously. For example, let's say you allow users to
upload multiple files and need to do some kind of processing on the files
and want to do that asynchronously. You can't do this right now.
<cfset aFiles = arrayNew(1) />
<cfset arrayAppend(aFiles, "c:\file_01.txt") />
<cfset arrayAppend(aFiles, "c:\file_02.txt") />
<cfset arrayAppend(aFiles, "c:\file_03.txt") />
<cfloop index="i" from="1" to="#arrayLen(aFiles)#">
<cfthread name="Thread_#i#">
<cfset results = doSomeProcessing(aFile[i]) />
<cfset doSomethingElse(results) />
</cfthread>
</cfloop>
The problem in the above example I that the variable "results" is the same
variable that all 3 threads would use. Also, I believe that even the
variable "i" isn't reliable--since it's not processed synchronously.
It seems to me, that maybe the following changes are needed:
* The variable scope in a thread should be separated from the calling
template (like in a custom tag.)
* Add a "thread" scope which could be used scope variables in a thread so
they can be used from the calling template after a join
* Add a thisThread scope to the thread which returns information about the
thread (maybe such keys as "name", so you could do thisThread.name to get
the defined name of the thread.)
In my opinion, you need to get threading to work so that the following code
would output the "results" down below:
<cfloop index="i" from="1" to="10">
<cfset sThreadName = "thread_" & i />
<cfset threads[sThreadName] = i />
<cfthread name="#sThreadName#">
<cfset thread.thisLoop = caller.threads[thisThread.name] />
<cfset thread.message = "I was spawned from loop " + thread.thisLoop />
</cfthread>
</cfloop>
<cfloop index="i" from="1" to="10">
<cfjoin thread="thread_#i#" />
</cfloop>
<cfloop index="i" from="1" to="10">
<cfset x = structGet("thread_#i#") />
<cfoutput>#x.message#</cfoutput> <br />
</cfloop>
The results should look like:
I was spawned from loop 1
I was spawned from loop 2
I was spawned from loop 3
I was spawned from loop 4
I was spawned from loop 5
I was spawned from loop 6
I was spawned from loop 7
I was spawned from loop 8
I was spawned from loop 9
I was spawned from loop 10
I'm not saying these tags aren't useful in their current state, but they are
severely limited. In the current state it's really easy to produce code that
won't work as expected.
-Dan
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting,
up-to-date ColdFusion information by your peers, delivered to your door four
times a year.
http://www.fusionauthority.com/quarterly
Archive:
http://www.houseoffusion.com/cf_lists/message.cfm/forumid:4/messageid:247332
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
