From: sk8save on
Let's say I launch a thread without joining it to the current page thread, what
happens to it when it's done?

I'm assuming it stays in memory until the GC comes and cleans it out? How long
would that take? Probably a setting in CF?

From: BKBK on
[i]I'm assuming it stays in memory until the GC comes and cleans it out?[/i]
I think so.

[i]How long would that take?[/i]
That is up to the garbage collector.

[i]Probably a setting in CF? [/i]
I don't know of any setting in CF to influence when the GC will operate on a
particular object. In fact I suspect such a setting does not exist.



From: sk8save on
I was testing a few things this Friday and ran out of threads, I couldn't add
more. I went into the server monitoring component and noticed that I had a ton
of threads running and several others queued. I'm pretty sure it was a
collection of all the threads I had created during the afternoon testing my
prototype.

Should I add a terminate call at the end to make sure they get disposed of
properly?

From: BKBK on
What do you mean when you say you couldn't add more? What was Coldfusion's
response?

It is always a good thing to make sure threads come to a graceful end. Also,
those that you want to continue should not be high consumers of memory.
Otherwise Coldfusion might come to a standstill.



From: sk8save on
My bad... I did a few more tests today and noticed the queued threads total
decreasing, 10 threads a time. At some point, it reached zero, so they do get
processed at some point. However, once my queued threads reached 0, I still had
104 threads running and it remained like that until I restarted the service in
which it reset to 0.

I just want to know what to do in order to have threads do what they are
supposed to and then stop using resources (memory, cpu, threads, ect...)

Is calling a terminate at the end of the thread make this possible or simply
making the thread run its course?

My goal is to write a small daemon thread that limits the number of threads
running. Once the max thread number drops, then the daemon thread starts
another one from the queue. The client is there waiting until his specific
thread is done (ajax refresh type thing).

Since the worker threads will have different timeout points (or there is no
possible way to determine how long the thread can take), I can't use event
gateways (at least I don't think so at the moment).