🚀 go-pugleaf

Hi,

I recently wrote a DLL that communicates with one of my EXE's via shared
memory.  The DLL is used by a third-party program and provides a means by
which the third-party application can communicate with my EXE.
Communication between the DLL and EXE works beautifully once communication
has been established.

When the third-party application calls a function in my DLL, my DLL creates
an inheritable memory-mapped file handle, then calls CreateProcess to start
my EXE and passes the memory-mapped file handle to my EXE as a command-line
parameter.  The EXE opens the memory-mapped file using the inherited handle
and begins to wait for commands from the DLL.

Communications synchronization is managed with a pair of named mutexes.
After calling CreateProcess to start the EXE, the DLL sleeps for 1 second
before sending any commands to the EXE, which typically gives the EXE enough
time to load and open the memory-mapped file and named mutexes.  However, I
am concerned that 1 second won't always be long enough in some cases, and
although not a big deal, 1 second might be more than is really necessary in
other cases.

If the DLL sends a request by signaling a mutex before the EXE has had a
chance to open the mutex, then even after the EXE has opened the mutex, the
EXE will not see that the mutex has been signaled, and consequently will
never respond to the command.  So my question is, how can the DLL know when
the EXE has opened the memory-mapped file and named mutexes, and is ready to
begin receiving requests?

Thanks,

- Dennis