tags:

views:

271

answers:

2

I'm designing a networking framework which uses WSAEventSelect for asynchronous operations. I spawn one thread for every 64th socket due to the max 64 events per thread limitation, and everything works as expected except for one thing:

Threads keep getting spawned uncontrollably by Winsock during connect and disconnect, threads that won't go away.

With the current design of the framework, two threads should be running when only a few sockets are active. And as expected, two threads are running in total. However, when I connect with a few sockets (1-5 sockets), an additional 3 threads are spawn which persist until I close the application. Also, when I lose connection on any of the sockets, 2 more threads are spawned (also persisting until closure). That's 7 threads in total, 5 of which I have no idea what they are there for.

If they are required by Winsock for connecting or whatever and then disappeared, that would be fine. But it bothers me that they persist until I close my application.

Is there anyone who could shed some light on this? Possibly a solution to avoid these threads or force them to close when no connections are active?

(Application is written in C++ with Win32 and Winsock 2.2)


Information from Process Explorer:

Expected threads:
MyApp.exe!WinMainCRTStartup
MyApp.exe!Netfw::NetworkThread::ThreadProc

Unexpected threads:
ntdll.dll!RtlpUnWaitCriticalSection+0x2dc
mswsock.dll+0x7426
ntdll.dll!RtlGetCurrentPeb+0x155
ntdll.dll!RtlGetCurrentPeb+0x155
ntdll.dll!RtlGetCurrentPeb+0x155

All of the unexpected threads have call stacks with calls to functions such as ntkrnlpa.exe!IoSetCompletionRoutineEx+0x46e which probably means it is a part of the notification mechanism.

+1  A: 

Download the sysinternals tool process explorer. Install the appropriate debugging tools for windows. In process explorer, set Options -> Symbols path to:

SRV*C:\Websymbols*http://msdl.microsoft.com/download/symbols

Where C:\Websymbols is just a place to store the symbol cache (I'd create a new empty directory for it.)

Now, you can inspect your program with process explorer. Double click the process, go to the threads tab, and it will show you where the threads started, how busy they are, and what their current callstack is.

That usually gives you a very good idea of what the threads are. If they're Winsock internal threads, I wouldn't worry about them, even if there are hundreds.

Andomar
Thank you for the advice. I have updated the post with information from Process Explorer, and it appears to be internal Winsock threads used for the notification mechanism.
kraf
Cool, look like those are winsock threads waiting on a kernel completion port. Those threads consume practically no resources while they are sleeping. So I guess this is a case where everything works as designed.
Andomar
+1  A: 

One direction to look in (just a guess): If these are TCP connections, these may be background threads to handle internal TCP-related timers. I don't know why they would use one thread per connection, but something has to do the background work there.

Tom