Handle leak in threading?

[Jayme Pechan]

I was wondering if someone could help me understand why it seems that
creating threads using the code below causes handles to seemingly leak.

System.Threadin g.Thread threadRunAsync = new
System.Threadin g.Thread(RunFun c);
threadRunAsync. Start(listParam s);

I have to use ThreadPools in order to avoid the handle leaks.

System.Threadin g.ThreadPool.Qu eueUserWorkItem (new
System.Threadin g.WaitCallback( RunFunc), listParams);

All I can figure is that it was done to discourage people from spawning
short lived threads and to encourage the use of thread pools. Any thoughts
that might help me understand this would be helpful. Sometimes I have items
that I'd like to run in a thread because they run for a long time and I
don't want the thread pool to be used up but I also don't want to have to
reboot my application every month either just to clear up the handles from
these threads. I thought about reverting to a whole new process for such
things but that's more painful.

Thanks

Jayme

[David Browne]

"Jayme Pechan" <ja**********@w hitefeld.com> wrote in message
news:u%******** *******@TK2MSFT NGP09.phx.gbl.. .

I was wondering if someone could help me understand why it seems that
creating threads using the code below causes handles to seemingly leak.

System.Threadin g.Thread threadRunAsync = new
System.Threadin g.Thread(RunFun c);
threadRunAsync. Start(listParam s);

I have to use ThreadPools in order to avoid the handle leaks.

System.Threadin g.ThreadPool.Qu eueUserWorkItem (new
System.Threadin g.WaitCallback( RunFunc), listParams);

All I can figure is that it was done to discourage people from spawning
short lived threads and to encourage the use of thread pools. Any
thoughts that might help me understand this would be helpful. Sometimes I
have items that I'd like to run in a thread because they run for a long
time and I don't want the thread pool to be used up but I also don't want
to have to reboot my application every month either just to clear up the
handles from these threads. I thought about reverting to a whole new
process for such things but that's more painful.

You are right not to use the ThreadPool for long-lived background tasks.

Spawing threads should not leak handles. Can you post a repro?

David

[Jayme Pechan]

My bad. It looks like it eventually clears the handles. I had it get up to
16k handles with a very simple program before it cleared them. I guess I
just have to be more patient with this garbage collector thing. It sure is
difficult to tell when you have memory problems in C# programs. I use a lot
of controls that are written in C++ so I have to pay attention to this. I
guess my unit testing will have to be the final word on the handles and
memory.

Thanks for the replay.

Jayme

[Willy Denoyette [MVP]]

"Jayme Pechan" <ja**********@w hitefeld.com> wrote in message
news:u%******** *******@TK2MSFT NGP09.phx.gbl.. .

I was wondering if someone could help me understand why it seems that
creating threads using the code below causes handles to seemingly leak.

System.Threadin g.Thread threadRunAsync = new
System.Threadin g.Thread(RunFun c);
threadRunAsync. Start(listParam s);

I have to use ThreadPools in order to avoid the handle leaks.

System.Threadin g.ThreadPool.Qu eueUserWorkItem (new
System.Threadin g.WaitCallback( RunFunc), listParams);

All I can figure is that it was done to discourage people from spawning
short lived threads and to encourage the use of thread pools. Any
thoughts that might help me understand this would be helpful. Sometimes I
have items that I'd like to run in a thread because they run for a long
time and I don't want the thread pool to be used up but I also don't want
to have to reboot my application every month either just to clear up the
handles from these threads. I thought about reverting to a whole new
process for such things but that's more painful.

Thanks

Jayme

Handles are unmanaged resources, it's your responsability to "dispose" them
of when you are done with them. If you don't, you may exhaust the handle
object pool before the GC comes along.

Willy.