philduba.com

Introduction
- multi-threading allows multiple tasks to run in parallel
- allows for harnessing the power of the processor for huge performance improvements

CFThread
- allows page to launch multiple tasks to run in parallel
- threads can run asynchronously
- use cases
    - fire and forget (just start it and don't care about it's completion, mail)
    - waiting for end

Use Cases
- Fire and Forget
    - lots of tasks for which end user does not need to wait
    - Image web application importing images from a user's flickr account, resize it and add to account
    - blog application that imports blog entries from another user's account
- Fire and wait to finish
    - lot of independent tasks that don't need to be synchronous
    - rss aggregator
    - travel portal going across airlines, hotels, etc.
    - essentially, each request is independent of itself, but display is together

First Look
<cfthread name=> any code </cfthread> and thus becomes multi-threaded

Execution Flow
- Good usage of PowerPoint animations to show thread spawning

How to create
<cfthread name="" [action=""] [priority=""]></cfthread>
- name is thread name and must be unique in the request, two different requests can have the same name.
- priority is set to normal by default, relates to JVM thread priority, and suggests fire and forget should be set to low

Internals
- thread body is extracted and a function is dynamically created - created at compile time
- function is invoked at runtime
- creates strange function in variables scope, a cfdump shows this

Key Concepts
- it has its own local scope, can use the var keyword
- any variable defined without a prefix in the thread, automatically puts it in the thread's local scope
- can access all other scopes but cannot write to session or client scope after the request is done (limitation of fire and forget)

Example - Fire and Forget
- doesn't use <cfthread action="join"/>

Example - Fire and Wait
- use Action "Join"
- can use a list of threads using name and comma-delimited list, not needed, if none present, it will wait for all threads launched in request to finish
- can set a timeout before moving own

Puzzles
- Rupesh shows some puzzles that showed why using variables in that are defined outside of a thread and utilized in a thread can result in different results than expected
- reason behind this, as explained by Sean in the audience very clearly since there was many puzzled faces, was that when using threads that access other variables, you can't guarantee that variables value at time of execution
- solution is to define an attribute during cfthread creation that can be passed in and its value is the expected value, just like a function's arguments scope. these values are duplicated/deep copied, not referenced - thread safe

Handling Output
- output from cfthread does not go into response, it goes into a output buffer which each thread has which can be retrieved using "output" key of thread scope, can use output="console" for cfdump to see it's output

Handling Errors
- error in CFThread does not terminate request spawn from
- done like normal error handling in cf page
- error meta-data is created but specific to thread

Thread Scope
- thread scope is only available in spawning request
- based on name of thread (i.e., thread.name) which can be used in output
- CFThread scope
    - does not go into variable scope
    - contains all thread scopes spawned in the request
    - lasts as long as request or last thread of request runs
    - can access using cfthread
    - uses during dynamic thread naming
        <cfset threadname="mythread">
        <cfset myoutput = cfthread[threadname].output> <-- this is also the output buffer here as well
    - similar to other CF tag scopes

Thread Meta-data
- name, priority, startTime, elapsedTime, Output, Error, Status
- all available in thread scope, which again, is the name of the thread itself. represented as a struct

Other actions
- Sleep suspends current thread for given duration but does not free up Java thread
- Terminate ends a thread, usage can lead to inconsistent operations if utilized too much. Java suggests not to kill a thread.

Working with shared resources
- For thread safety, use CFLock
- lock on request scope or any subscope such as form, url, etc.

Administration
- can set maximum number of threads in administrator
- can set timeout for idle threads, i.e., all threads are in use, and more threads queue up and this timeout will kill a thread that has been waiting that long for its execution
- careful with setting of these values as too high and resources will be drained, too low and threads can be dropped
- not the same as the "thread" setting at the top of the CF Administrator (answer to a audience question) - look in the Tag Limit Settings area of Settings page
- can monitor, use alerts own and use admin API for monitoring