🚀 go-pugleaf

"Dennis Jones" <djones@nospam.com> wrote in message
news:4040bd56$1@newsgroups.borland.com...

> And now that I think
> about it, I might have been able to do the same thing with one of my
> mutexes too.  After all, I was able to wait on the event handle before
> the EXE had opened its own handle to it -- so why not a mutex?

I do not recommend a mutex.  The DLL cannot wait for the EXE to signal a
mutex as easily as it can an event.  As soon as the DLL creates the mutex,
it would usually end up obtaining ownership of the mutex before the
application could open it.  Thus the EXE would be waiting on the DLL, not
the other way around.  An event is better suited for this task instead.

> Given that the event worked, and that it seems likely that a mutex
> would work the same way

Not exactly.

> it seems odd to me that one could not open a mutex, set it to
> the signaled state, and then have another process open a handle
> to that same mutex and have a wait succeed.

A mutex is signaled when it is unowned.  The first process to call
WaitForSingleObject() will own the mutex and set it back to unsignaled so
other processes wait for it.  If the DLL creates it first, changes are the
DLL will become the first owner, not the EXE.  But you wanted the DLL to
wait on the EXE, not the other way around, so a mutex does not work very
well for that.


Gambit