I saw something interesting when testing my multi-threaded code to make sure
that threads were terminating as I expected. When I first bring up my
WinForms test application (before I do any Thread.Start), I notice that my
process has 4 threads initially. Does anyone know what the other 3 threads
in my app's process are for?
Also, I posted a question earlier about getting an initial delay after
calling Thread.Abort (yes, I know it's not wise to do it, but I wanted to
dig further to see what caused the delay). Anyway, what I found was that
..NET was actually spinning up 2 other threads during this "extra" time, and
then killed the threads after it did something in the background. Probably
some kind of exception (on top of my exception handling), or cleanup.
Anyway, the thread count bounces up only on the very first Thread.Abort. If
I re-create a new thread and abort it, this scenario (and the delay) doesn't
occur.
--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at: http://www.ddconsult.com/blogs/illuminati/ 7  9116 
I think you're seeing are
The GC Thread
The Finalization Thread
The ThreadPool Manager Thread
I'm not sure whats happening with the Thread.Abort scenario at the moment but maybe digging in the ROTOR source might give you some clue
Regards
Richard Blewett - DevelopMentor http://staff.develop.com/richardb/weblog
I saw something interesting when testing my multi-threaded code to make sure
that threads were terminating as I expected. When I first bring up my
WinForms test application (before I do any Thread.Start), I notice that my
process has 4 threads initially. Does anyone know what the other 3 threads
in my app's process are for?
Also, I posted a question earlier about getting an initial delay after
calling Thread.Abort (yes, I know it's not wise to do it, but I wanted to
dig further to see what caused the delay). Anyway, what I found was that
.NET was actually spinning up 2 other threads during this "extra" time, and
then killed the threads after it did something in the background. Probably
some kind of exception (on top of my exception handling), or cleanup.
Anyway, the thread count bounces up only on the very first Thread.Abort. If
I re-create a new thread and abort it, this scenario (and the delay) doesn't
occur.
--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at: http://www.ddconsult.com/blogs/illuminati/
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system ( http://www.grisoft.com).
Version: 6.0.775 / Virus Database: 522 - Release Date: 08/10/2004
[microsoft.public.dotnet.languages.csharp]
"Doug Thews" <do*******@removeme.ddconsult.com> wrote in message
news:uY**************@TK2MSFTNGP12.phx.gbl... I saw something interesting when testing my multi-threaded code to make
sure that threads were terminating as I expected. When I first bring up my
WinForms test application (before I do any Thread.Start), I notice that my
process has 4 threads initially. Does anyone know what the other 3 threads
in my app's process are for?
As Richard stated, the threads could be for GC, threadpool, and the
finalization queue. The 4th could be the main thread of your application.
Also, I posted a question earlier about getting an initial delay after
calling Thread.Abort (yes, I know it's not wise to do it, but I wanted to
dig further to see what caused the delay). Anyway, what I found was that
.NET was actually spinning up 2 other threads during this "extra" time,
and then killed the threads after it did something in the background.
Probably some kind of exception (on top of my exception handling), or
cleanup. Anyway, the thread count bounces up only on the very first
Thread.Abort. If I re-create a new thread and abort it, this scenario
(and the delay) doesn't occur.
Were you running under a debugger when you threw the abort? If so, then it
could be the debugger spinning up some threads to synchronize access to the
debugged application. Even when not running under a debugger it could be the
win32 subsystem creating a thread to notify any attached debuggers of a 1st
chance exception.
Cool, thanks for the info. So, ANY WinForms .NET application is going to
have 4 threads to start? I guess I'd always thought of the .NET runtime as
a single instance, so the GC, etc would exist in their own little worlds,
being called on the .NET AppDomains when necessary.
--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at: http://www.ddconsult.com/blogs/illuminati/
"David Levine" <no****************@wi.rr.com> wrote in message
news:OJ*************@TK2MSFTNGP15.phx.gbl... "Doug Thews" <do*******@removeme.ddconsult.com> wrote in message
news:uY**************@TK2MSFTNGP12.phx.gbl...I saw something interesting when testing my multi-threaded code to make
sure that threads were terminating as I expected. When I first bring up
my WinForms test application (before I do any Thread.Start), I notice that
my process has 4 threads initially. Does anyone know what the other 3
threads in my app's process are for?
As Richard stated, the threads could be for GC, threadpool, and the
finalization queue. The 4th could be the main thread of your application.
Also, I posted a question earlier about getting an initial delay after
calling Thread.Abort (yes, I know it's not wise to do it, but I wanted to
dig further to see what caused the delay). Anyway, what I found was that
.NET was actually spinning up 2 other threads during this "extra" time,
and then killed the threads after it did something in the background.
Probably some kind of exception (on top of my exception handling), or
cleanup. Anyway, the thread count bounces up only on the very first
Thread.Abort. If I re-create a new thread and abort it, this scenario
(and the delay) doesn't occur.
Were you running under a debugger when you threw the abort? If so, then it
could be the debugger spinning up some threads to synchronize access to
the debugged application. Even when not running under a debugger it could
be the win32 subsystem creating a thread to notify any attached debuggers
of a 1st chance exception.
Hmm..I actually think that ANY .NET app (not just Winforms) would have 4
threads on startup - but I have to check this though. One way to check this
is to load up WinDbg and use the threads command to see what is running in
what
--
Sriram Krishnan http://www.dotnetjunkies.com/weblog/sriram
"Doug Thews" <do*******@removeme.ddconsult.com> wrote in message
news:eB**************@tk2msftngp13.phx.gbl... Cool, thanks for the info. So, ANY WinForms .NET application is going to
have 4 threads to start? I guess I'd always thought of the .NET runtime
as a single instance, so the GC, etc would exist in their own little
worlds, being called on the .NET AppDomains when necessary.
--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/
"David Levine" <no****************@wi.rr.com> wrote in message
news:OJ*************@TK2MSFTNGP15.phx.gbl... "Doug Thews" <do*******@removeme.ddconsult.com> wrote in message
news:uY**************@TK2MSFTNGP12.phx.gbl...I saw something interesting when testing my multi-threaded code to make
sure that threads were terminating as I expected. When I first bring up
my WinForms test application (before I do any Thread.Start), I notice
that my process has 4 threads initially. Does anyone know what the other
3 threads in my app's process are for?
As Richard stated, the threads could be for GC, threadpool, and the
finalization queue. The 4th could be the main thread of your application.
Also, I posted a question earlier about getting an initial delay after
calling Thread.Abort (yes, I know it's not wise to do it, but I wanted
to dig further to see what caused the delay). Anyway, what I found was
that .NET was actually spinning up 2 other threads during this "extra"
time, and then killed the threads after it did something in the
background. Probably some kind of exception (on top of my exception
handling), or cleanup. Anyway, the thread count bounces up only on the
very first Thread.Abort. If I re-create a new thread and abort it, this
scenario (and the delay) doesn't occur.
Were you running under a debugger when you threw the abort? If so, then
it could be the debugger spinning up some threads to synchronize access
to the debugged application. Even when not running under a debugger it
could be the win32 subsystem creating a thread to notify any attached
debuggers of a 1st chance exception.
This is the minimum number of threads created when running the workstation
version of the CLR.
Two of them are managed threads (EE threads) the other two are used for
debugging services.
Thread 0 : Applications main thread (managed)
Thread 1 : Debugger Runtime Controller thread (unmanaged)
Thread 2 : Finalizer thread (managed)
Thread 3 : Debugger thread (unmanaged)
Willy.
"Doug Thews" <do*******@removeme.ddconsult.com> wrote in message
news:uY**************@TK2MSFTNGP12.phx.gbl... I saw something interesting when testing my multi-threaded code to make
sure that threads were terminating as I expected. When I first bring up my
WinForms test application (before I do any Thread.Start), I notice that my
process has 4 threads initially. Does anyone know what the other 3 threads
in my app's process are for?
Also, I posted a question earlier about getting an initial delay after
calling Thread.Abort (yes, I know it's not wise to do it, but I wanted to
dig further to see what caused the delay). Anyway, what I found was that
.NET was actually spinning up 2 other threads during this "extra" time,
and then killed the threads after it did something in the background.
Probably some kind of exception (on top of my exception handling), or
cleanup. Anyway, the thread count bounces up only on the very first
Thread.Abort. If I re-create a new thread and abort it, this scenario
(and the delay) doesn't occur.
--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/
If the app is compiled for "release" mode (i.e. no debug), then will the 2
debugger threads not get instantiated?
--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at: http://www.ddconsult.com/blogs/illuminati/
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:eG**************@TK2MSFTNGP12.phx.gbl... This is the minimum number of threads created when running the workstation
version of the CLR.
Two of them are managed threads (EE threads) the other two are used for
debugging services.
Thread 0 : Applications main thread (managed)
Thread 1 : Debugger Runtime Controller thread (unmanaged)
Thread 2 : Finalizer thread (managed)
Thread 3 : Debugger thread (unmanaged)
Willy.
"Doug Thews" <do*******@removeme.ddconsult.com> wrote in message
news:uY**************@TK2MSFTNGP12.phx.gbl...I saw something interesting when testing my multi-threaded code to make
sure that threads were terminating as I expected. When I first bring up
my WinForms test application (before I do any Thread.Start), I notice that
my process has 4 threads initially. Does anyone know what the other 3
threads in my app's process are for?
Also, I posted a question earlier about getting an initial delay after
calling Thread.Abort (yes, I know it's not wise to do it, but I wanted to
dig further to see what caused the delay). Anyway, what I found was that
.NET was actually spinning up 2 other threads during this "extra" time,
and then killed the threads after it did something in the background.
Probably some kind of exception (on top of my exception handling), or
cleanup. Anyway, the thread count bounces up only on the very first
Thread.Abort. If I re-create a new thread and abort it, this scenario
(and the delay) doesn't occur.
--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/
Both are unrelated, you can also debug "non debug" assemblies, or
dynamically loaded assemblies don't you?
The two threads are always created before Execution Engine startup, this is
done long before the assembly loader kicks in.
Note that these threads are used to debug the CLR itself and that the
DebuggerRCThread also serves many other purposes like profiler and perfmon
IPC(delivering CLR perfcounters).
Willy.
"Doug Thews" <do*******@removeme.ddconsult.com> wrote in message
news:ed**************@tk2msftngp13.phx.gbl... If the app is compiled for "release" mode (i.e. no debug), then will the 2
debugger threads not get instantiated?
--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:eG**************@TK2MSFTNGP12.phx.gbl... This is the minimum number of threads created when running the
workstation version of the CLR.
Two of them are managed threads (EE threads) the other two are used for
debugging services.
Thread 0 : Applications main thread (managed)
Thread 1 : Debugger Runtime Controller thread (unmanaged)
Thread 2 : Finalizer thread (managed)
Thread 3 : Debugger thread (unmanaged)
Willy.
"Doug Thews" <do*******@removeme.ddconsult.com> wrote in message
news:uY**************@TK2MSFTNGP12.phx.gbl...I saw something interesting when testing my multi-threaded code to make
sure that threads were terminating as I expected. When I first bring up
my WinForms test application (before I do any Thread.Start), I notice
that my process has 4 threads initially. Does anyone know what the other
3 threads in my app's process are for?
Also, I posted a question earlier about getting an initial delay after
calling Thread.Abort (yes, I know it's not wise to do it, but I wanted
to dig further to see what caused the delay). Anyway, what I found was
that .NET was actually spinning up 2 other threads during this "extra"
time, and then killed the threads after it did something in the
background. Probably some kind of exception (on top of my exception
handling), or cleanup. Anyway, the thread count bounces up only on the
very first Thread.Abort. If I re-create a new thread and abort it, this
scenario (and the delay) doesn't occur.
--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Morgan Leppink |
last post by:
Hi all -
We have been developing a complex TCP socket communication
app that is responsible for keeping numerous connections
open to clients on routable IPs. The app receives request
on a...
|
by: Amadej |
last post by:
Hello everyone
I have a beginner's questions about the System.Threading.Timer class
behavior. I have been observing the thread count with Windows Task
Manger and noticed that timers, after being...
|
by: Razzie |
last post by:
Hi all,
A question from someone on a website got me thinking about this, and I
wondered if anyone could explain this.
A System.Threading.Timer object is garbage collected if it has no...
|
by: cider123 |
last post by:
I have a simple Window Service that loads up a list of Folders to
monitor, along with parameters for a maintenance profile.
Every time the interval is reached, the Window Service spawns off a...
|
by: Steve |
last post by:
Hello,
I have a subroutine, sub1 that creates 2 new Threads.
Each Thread then runs a subroutine of their own. Sub1 is
on a timer and when called will create 2 new threads each
time. I...
|
by: Griff |
last post by:
Hi folks,
I need help understanding the reported thread counts on a system.
We are running a .NET 2.0 service on a quad CPU box. The service
programmatically sets a maximum of 300 worker and...
|
by: fniles |
last post by:
I am using VB.NET 2003 and a socket control to receive and sending data to
clients.
As I receive data in 1 thread, I put it into an arraylist, and then I remove
the data from arraylist and send it...
|
by: Amit Dedhia |
last post by:
Hi
I am developing a scientific application which has moderate level
image processing involved.
In my application, there is a main application form which invokes
another form. When this form...
|
by: lagu2653 via DotNetMonster.com |
last post by:
I have a log-in window application. When the user presses the cancel button
it kills another window by it's name and then it exits. The problem is that
if somebody kills the log-in window by...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
