Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Joe O'Leary (jmolearyEARTHLINK.NET)
Date: Thu Feb 14 2002 - 08:30:53 CST
>Joe O'Leary wrote:
> > Far better to abandon a thread than to terminate it.
> For sure, but also, realize something that no one has mentioned yet in
> here: each thread has a (fairly sizable) call stack, often 1 MB. For
> every thread you abandon, you're abandoning 1 MB of VM in most cases.
> That's lost address space. Your process can only address up to 2048 MB
> of writable memory (unless you're running W2K with the /3GB switch)
> which means you could run out of address space pretty quickly if you're
> abandoning a lot of threads.
It's true that leaving each thread running as I suggested will mean you effectively leak that thread's stack. However terminating the thread will not make things any better.
When you terminate a thread, *none* of its resources are reclaimed. That includes its stack. You lose the stack memory either way. And at least by leaving the thread running and not suspending it, you have a *chance* that the it might eventually come back from it's DCOM call and terminate normally -- thereby reclaiming all that stack memory.
But if it comes down to a choice between suspending a prodical thread and terminating it, suspending it is the lesser of the two evils.
> Also, you could end up starving the thread pool that the abandoned
> threads come from. If this is your thread pool, you can deal with it by
> creating more threads. But if it's, say, the RPC thread pool, then it
> might have its own ideas about upper limits on the number of threads,
> and you could end up with all of your RPC threads blocked somewhere,
> suspended, etc.
Fortunately, Steve Swartz cleared things up (in another post here) by confirming what I've long suspected (but never knew for sure):
"RPC will create threads indefinitely as
new work comes in and no threads are
> (Thread starvation is also a concern if you're planning
> on calling TerminateThread on a thread from someone else's thread pool,
> as it will likely corrupt whatever throttling mechanism it's using.)
Amen to that. Terminating your own thread is never good programming practice (IMHO). Terminating someone else's thread is simply asking for disaster. You have absolutely no idea what will happen to your application.
---------------------------------------------------------------- Users Guide http://discuss.microsoft.com/archives/mailfaq.asp contains important info. Save time, search the archives at http://discuss.microsoft.com/archives/index.html . To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM