🚀 go-pugleaf

"Remy Lebeau (TeamB)" <gambit47.no.spam@no.spam.yahoo.com> wrote in message
news:403f8f1c@newsgroups.borland.com...
>
> "Dennis Jones" <djones@nospam.com> wrote in message
> news:403f6f4c$1@newsgroups.borland.com...
>
> > No, I don't think so...if the DLL waits on the mutex before the
> > EXE has opened a handle to it, the wait call will succeed
> > immediately because the DLL will already have ownership of
> > the mutex (because it created it).
>
> That is not what Bob was suggesting.  Have the DLL create a second object,
> such as an event object via CreateEvent() that is initially unsignalled.
> Then have the EXE open that same event and signal the event when the EXE
is
> ready.  The DLL can wait for the event to be signalled before doing
anything
> else with the EXE.

I certainly didn't read that into Bob's message, but it was an awfully good
suggestion -- and it worked beautifully.  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?

Given that the event worked, and that it seems likely that a mutex would
work the same way, 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.  Maybe I should take another look
at my code; it could be that when I tried this with a mutex I opened it in
the non-signaled state thereby preventing the other process's wait from
succeeding.

Thanks,

- Dennis