Hello, Doug!

"Last thread standing" scenario is bad. Because application can have several
threads started by CLR and there is no guarantee that your thread will be
the last to stop.

Process class from System.Diagnostics has Threads property. Using this
property you can query for you thread.

But if we're talking about library code you can still handle
ThreadAbortException within your thread to do necessary cleanup. Anothew way
is to provide some close API for your library that is mandatory to call.
--
With best regards, Vadym Stetsiak.
Blog: http://vadmyst.blogspot.com

You wrote  on Tue, 02 Oct 2007 15:45:59 -0000:

DS> Is there any way to detect/count the number of application defined
DS> foreground threads that are currently active?

DS> Background:  We have a library that processes application requests
DS> in the background via a queuing mechanism (basically the library has
DS> one thread that does the work, and the application's calls into the
DS> library just puts the item to be processed on a queue).  Before you
DS> say it, no MSMQ is not an option.  The problem is that there may be
DS> items remaining in the queue when the application shuts down...that
DS> need to be flushed.  If I make the worker thread a foreground
DS> thread, an application will never shut down completely because the
DS> CLR doesn't shutdown an app until all foreground threads have
DS> exited.  If I make it a background thread, and the application shuts
DS> down, but since the thread is basically aborted by the CLR, the
DS> final items that need to be processed are not.

DS> I have tried trapping the various events (AppDomain.DomainUnload,
DS> etc), but the CLR usually pulls the rug out from under me.  I tried
DS> finalizing, but as we know, the finalizer doesn't necessarily get
DS> called.

DS> What I need is basically to put my thread as a foreground thread,
DS> and detect whether or not I am the "last thread standing" so I can
DS> do my cleanup.

DS> (We have a workaround requirement that an application must call a
DS> "AppIsShuttingDown" function before it closes its last thread, but
DS> I've noticed some of my colleagues are ignoring that requirement).