Thanks for the confirmation +Peter Gejdeman
. You know, I haven't made the change and I think you're using it way more consistently than myself. My purpose is to communicate with a running process under a service via this IPC method. It's funny we're using the same code.
I haven't done very much stress testing of it. When I saw your posting, I went through and looked into the source code for "MsgWaitForMultipleObjects" and found..
File: I:\projects\thirdparty\pipes\Pipes.pas 3 occurrences found on 3 lines
1804: case MsgWaitForMultipleObjects(1, hEvent, False, INFINITE, QS_SENDMESSAGE) of
3283: while (MsgWaitForMultipleObjects(1, FEmpty, False, INFINITE, QS_SENDMESSAGE) = WAIT_OBJECT_0 + 1) do
4144: while (MsgWaitForMultipleObjects(1, hThread, False, INFINITE, QS_ALLINPUT) = WAIT_OBJECT_0 + 1) do
In going through my changelog for the unit, I made several changes for XE2 (as I kept it AnsiString) and one change to the "TPipeListenThread.Create()" (see below).
// Increment the thread counter
FPipeServer.FThreadCount.Increment; // *
2010-12-01: MMC -- Moved this line from just after the "inherited Create(TRUE)" to after the assignment has been made to the property