Thread has exited?

  • Thread starter Thread starter Drew
  • Start date Start date
D

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
 
Drew said:
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.
Click to expand...

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
 
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
 
When you run any program the system creates a thread for it.
Maybe this is simply the thread your program is running on?
 
Drew said:
Is there any way to tell what generated this thread in the first place?
Click to expand...

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?
Click to expand...

I doubt it.

Ivan
 
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
 
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.
 
Dave said:
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.
Click to expand...

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, 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.
Click to expand...

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
 
Jon Skeet said:
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.
Click to expand...

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.
 
Back
Top