tracker issue : CF-3644151

select a category, or use search below
(searches all categories and all time range)
Title:

Another suggested tweak to CFScript: thread

| View in Tracker

Status/Resolution/Reason: To Fix//EnhancementRequired

Reporter/Name(from Bugbase): Adam Cameron / Adam Cameron (Adam Cameron)

Created: 10/02/2013

Components: Language

Versions: 10.0

Failure Type: Enhancement Request

Found In Build/Fixed In Build: Final /

Priority/Frequency: Trivial / Unknown

Locale/System: English / Platforms All

Vote Count: 2

See http://cfmlblog.adamcameron.me/2013/10/another-suggested-tweak-to-cfscript.html

Extract:
CFScript's support for <cfthread> is another one of those weirdly-syntaxed things like savecontent:

thread name="t1" action="run" someattribute="value" {
    // stuff here
}

What I think this should be like is this:

t1 = Thread.new({someattribute="value"}) {
    // stuff here
}

In this example the run is implicit... perhaps it could be decoupled? Would one want to do that? EG:

t1 = Thread.new({someattribute="value"}) {
    // stuff here
}
t1.run();

Obviously there's other modes to deal with here too.


Thread.join([t1,t2,t3]);

Note that this is not an object method, it's a class method (static method, whatever), ie it's not - following on from the code above:

t1.join([t2,t3]);

I'm not sure it makes sense for a join operation to be a method of a thread object? But it could be, I dunno.

That leaves sleep and and terminate. Easy:

t1.sleep(1000);
t1.terminate();

I think that's much better syntax than what we have now, and makes more sense.

Another thing that this opens up is that perhaps this means there could be other methods on the Thread object: checking its status ("running", "sleeping", "terminated", "finished" etc) and maybe other telemetry? Or being able to alter time outs and priority on the fly (is this possible though?) and stuff. Dunno. It adds scope for such enhancements anyhow.

I've been pushing for CFML to become more OO than it currently is: "Improving ColdFusion CFML's OO-ness", hence being OK with the OO-style syntax here. This is the direction CFML needs to move (and is moving... more on that in a follow-up article...), but if we had to stay all procedural about things, all the above could be dealt with with four new functions:

threadNew()
threadJoin()
threadSleep()
threadTerminate()

But I think we can agree that is not a way forward.

-- 
Adam

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3644151

External Customer Info:
External Company:  
External Customer Name: Adam Cameron.
External Customer Email:  
External Test Config: My Hardware and Environment details:

Attachments:

Comments:

Got my vote! I'd rather see it look like this... Of course, now we have to support the existing syntax too for backwards compat. :(
Vote by External U.
14364 | October 02, 2013 07:32:38 AM GMT
Thread control, being a truly programmatic construct, must absolutely be represented as a set of scripted functions. This would simplify a lot of code for multi threaded applications.
Vote by External U.
14365 | October 09, 2013 07:10:02 AM GMT
Hey Adobe, is there any target for this implementation? Just saying "to fix" isn't in itself very helpful information.
Comment by External U.
14363 | November 05, 2015 03:32:57 AM GMT