Thread has exited?

[Drew]

I keep seeing this when I run my program in Visual Studio:

The thread '<No Name>' (0x894) has exited with code 0 (0x0).

What does this mean exactly? It doesn't seem to be causing a problem.

Thanks,

Drew

 

[Ivan Krivyakov]

I keep seeing this when I run my program in Visual Studio:

The thread '<No Name>' (0x894) has exited with code 0 (0x0).

What does this mean exactly? It doesn't seem to be causing a problem.

It means exactly what it says.
A thread with ID 0x894 has finished execution and returned 0.
This is normal condition, not a problem.

It means that either you or someone on your behalf created a new
thread of execution, and that thread has just finished.

In C# you create threads using System.Threading.Thread class.

Ivan

 

[Drew]

Is there any way to tell what generated this thread in the first place?

It doesn't appear to be anything that I created directly.

Could the thread be generated by calling Refresh() on a GUI component?

Drew

 

[Sharon]

When you run any program the system creates a thread for it.
Maybe this is simply the thread your program is running on?

 

[Ivan Krivyakov]

Is there any way to tell what generated this thread in the first place?

I am not sure.

I guess you can interrupt your program and see what threads are executing
(Debug->Windows->Threads). I know Microsoft Jet database engine (the one
called when you access .MDB files) has habit of creating additional threads.

Could the thread be generated by calling Refresh() on a GUI component?

I doubt it.

Ivan

 

[Drew]

Except that I see these messages while the program is running.

I would think that if this was the main thread, it would only display
this message upon exiting the program...

I will see if I can isolate where it's coming from.

Drew

 

[Dave]

Drew, it may be a thread from the thread pool. These threads are created and
destroyed dynamically. Operations that are asynchronous often are completed
on a threadpool thread, such as network operations and timers.

If you are creating threads yourself you can give each one a name by setting
the Name property of the thread object; when the thread is destroyed it will
report the name. If it is a threadpool thread then it will not have a name.

 

[Jon Skeet [C# MVP]]

Drew, it may be a thread from the thread pool. These threads are created and
destroyed dynamically. Operations that are asynchronous often are completed
on a threadpool thread, such as network operations and timers.

But the point of a threadpool thread (in the current implementation) is
that it *doesn't* get destroyed - it hangs around for more work to do.
A more generalised threadpool may indeed create and destroy threads
based on various criteria, but I believe the .NET one just creates a
fixed number (25 per processor?) and leaves them there waiting for
work.

 

[Drew]

Drew, it may be a thread from the thread pool. These threads are created
and

destroyed dynamically. Operations that are asynchronous often are completed
on a threadpool thread, such as network operations and timers.

OK then it's probably a thread from the network connection I created inside
my own
thread. I did give my own thread a name and I can see when that stops
running.

However, I'm using the GetResponse method from HttpWebRequest and the docs
state that this method is synchronous. Does this also mean that it is non
blocking?

Actually, I think I would prefer that the connection would block until some
data
is received or a timeout exception occurs. Can I specify this with
HttpWebRequest?

Regards,

Drew

 

[Dave]

But the point of a threadpool thread (in the current implementation) is
that it *doesn't* get destroyed - it hangs around for more work to do.
A more generalised threadpool may indeed create and destroy threads
based on various criteria, but I believe the .NET one just creates a
fixed number (25 per processor?) and leaves them there waiting for
work.

I don't believe that's true - threadpool threads get created only as needed.
I just built a simple test app, queued up some work items, and the thread(s)
got created as I expected but I did not see them get destroyed. I had
thought there was a decay timer associated with each thread, and if enough
time goes by the thread would get destroyed, but either the implementation
changed, I was misinformed, or the conditions for destroying the thread
never occurred.


Our client application makes extensive use of web services, and after some
network traffic we always see the message that threads are getting
destroyed, so I know there is dynamic creation/destruction of threads. I
still believe these are threadpool threads but I would have to do more
investigation to prove it.