Is it your driver? Make it allow multiple processes to open the device.
If you can't change the driver, you're still in good shape. All the IPC
applications use. The DLL won't use DeviceIoControl any more, it will
world. But, when I ported this to XP, only one application at a time
could bind to the protocol driver, the other would get "The requested
resource is in use." errors.
So, I'm trying to find a way to modify the DLL such that the first
process that loads it and runs the Open() function goes through the
procedure of opening the protocol driver and binding to it. If the DLL
is loaded by a second process, while it's still being used by the
first process, then it just uses the bindings created by the first
process.
Am I still in the same boat?
Any idea why this isn't a problem under WinCE?
Thanks,
Paul
On Jul 23, 1:34 pm, "Ben Voigt [C++ MVP]" <r...@nospam.nospam> wrote:
"PaulH" <paul.h...@gmail.com> wrote in message
news:1185210047.440472.182490@g4g2000hsf.googlegroups.com...
Instead of using IPC, wouldn't it be possible to use DuplicateHandle()
such that ProcessA opens the DLL and gets the original resource
handle, then Process B opens the DLL and gets a DuplicateHandle()?
I'm glad you mentioned the second process. I didn't consider what
would happen to Process B if Process A closed the resource. What about
using the DLL to keep a reference count of all the handles created,
then it could wait for the reference to become 0 before it really
releases the resource. Would that work?
What if I call TerminateProcess on process A? (Perhaps via Task
Manager ->
End Process) Then
(1) Your cleanup code in process A won't run.
(2) Any resources owned by process A get freed by Windows.
I'm not sure, maybe DuplicateHandle fixes problem #2. #1 is still going
to
be a big problem. Even to call DuplicateHandle the second process needs
a
handle to the first, and the value of the resource handle inside the
first
process. This is non-trivial when the first process quits. Then you
have
to replace the shared data with another process's copy of the handle...
you're going to need shared segments and cross-process (named) mutexes to
synchronize access to the shared data. Probably easier to just go with a
named pipe.