debugging - When windows releases threads? -


our product consumes lot of windows resources, such socket handles, memory, threads , on. there 700-900 active threads, in cases product can rapidly create new threads , work, , close it. came across crash memory dump of our product. ~* windbg command can see 817 active threads, when run !handle command prints me these summary:

 type            count none            15 event           2603 section         13 file            705 directory       4 mutant          32 windowstation   2 semaphore       789 key             208 process         1 thread          5766 desktop         1 iocompletion    308 timer           276 keyedevent      1 tpworkerfactory 48 

so, process holds 5766 threads. so, question, when windows frees handles process? possible kind of delay, or cashing? can explain behavior? don't think have handle leaks, have weird behavior in legacy part of system rapidly creating , closing threads small tasks. point, unlikely run more 1000 threads simultaneously, pretty sure this. thanks.

when so, process holds 5766 threads., mean process holds 5766 thread handles.

even though thread may no longer running, whether result of call exitthread()/terminatethread() or returning threadproc, handles thread remain valid. makes possible things call getexitcodethread() on handle of thread has finished work.

unfortunately, means have remember call closehandle() instead of letting leak. msdn example on creating threads covers extent.

another thing note somewhere not far above 1000 running threads, exhaust amount of virtual address space available 32bit process since each thread default reserves 1mb of address space stack.


Comments

Popular posts from this blog

Why does Ruby on Rails generate add a blank line to the end of a file? -

node.js - Bad Request - node js ajax post -

uitableview - Create and use custom prototype table cells in xamarin ios using storyboard -