I have a windows service that updates a software package in the background. the main program communicates with this service by means of a named pipe. the buffer size for the pipe is 4096 bytes. when I spawn a new thread for each pipe connection, it appears to leak memory in approximately the amount of the pipe buffer size for each thread I create. I can handle connections without spawning threads, because the connection handles one request and then closes, and requests are responded to very quickly.
The main thread spawning loop:
Code:
#define BUFSIZE 4096
while (true)
{
HANDLE hPipe = CreateNamedPipe(lpszPipename, // pipe name
PIPE_ACCESS_DUPLEX, // read/write access
PIPE_TYPE_BYTE | // message type pipe
PIPE_READMODE_BYTE | // message-read mode
PIPE_WAIT, // blocking mode
PIPE_UNLIMITED_INSTANCES, // max. instances
BUFSIZE, // output buffer size
BUFSIZE, // input buffer size
0, // client time-out
NULL); // default security attribute
if (hPipe == INVALID_HANDLE_VALUE)
{
return 0xFFFFFFFF;
}
fConnected = ConnectNamedPipe(hPipe, NULL) ? TRUE : (GetLastError() == ERROR_PIPE_CONNECTED);
if (fConnected)
{
HANDLE hThread = NULL;
unsigned int threadid = 0;
ThreadUpdaterStatus* tus = new ThreadUpdaterStatus;
tus->hPipe = hPipe;
tus->upd = (UpdaterStatus*)data;
hThread = (HANDLE)_beginthreadex(NULL, 0x10000, (THREADPROC)PipeClientThread, (void*)tus, 0, &threadid);
if (!hThread) return 0xFFFFFFFF;
CloseHandle(hThread);
}
}
The thread function:
Code:
unsigned int WINAPI PipeClientThread(volatile ThreadUpdaterStatus* data)
{
HANDLE hPipe = data->hPipe;
UpdaterStatus* upd = data->upd;
// Read data from pipe
ReadFile(hPipe...);
// Process Request
// Write data to pipe
WriteFile(hPipe...);
FlushFileBuffers(hPipe);
DisconnectNamedPipe(hPipe);
CloseHandle(hPipe);
_endthreadex(0);
return 0;
}
My question is simply this: is there anything else I need to do with the pipe or the thread when the thread terminates? the tutorials I read on pipes and threads don't mention anything else, but in my experience, tutorials give you enough to get it working, and sometimes skimp on the real details. This service cannot be allowed to eat up 4k every second until the machine comes crashing down.