Re-entrancy problem ...

Re-entrancy problem ...

Post by Richard.Go » Sun, 05 Dec 2004 03:25:33


Here's my situtation ...

Client A -> Proxy Object B -> Service Object C

The code in "A" is something like:

-------------------------------
CreateObject ("B")
B.Open

B.Close
Set B = Nothing
-------------------------------

The code in "C" represents/connects to a single hardware device - and
it fires some methods on "B" when various attributes of the hardware
change

Proxy object B is implemented as a COM service EXE - the thoughts
behind were so that multiple clients could create the proxy object "B"
- and the code within the COM EXE could share the same physical
connection to the device. The reason for a "service" EXE and not a
normal "EXE" was so that this can be accomplished between foreground
processes and services (i.e. LocalSystem account ones).

Now for the issue ... the service object "C" calls a method on "B" to
indicate that part of the hardware status has changed - within method
"B", a call back to client "A" is "IDispatch::Invoked'd" (keep in mind
now, that because of the cross-aparament/cross-process call, this call
to "A" passes through a message pump) - before this "Invoke" call
returns, the client "A" calls the B.Close and "Set B = Nothing" -
which calls the "Close" method on "B" and the releases/frees object
"B". Once this is finished, the original "IDispatch::invoke" call
that was going back to "A" returns - and begins executing in an
object/memory space that no longer exists.

In particular, I'm trying to solve the re-entrancy problem I've got on
object "B" - although I'm open to other solutions which would
ultimately allow multiple clients to access the same object "C" (note
that I have no access to the code for "C" - that is why I'm trying
this via a "proxy" object)

Thoughts/comments on this issue?

Thanks,
Richard Gohs
 
 
 

Re-entrancy problem ...

Post by Alexander » Sun, 05 Dec 2004 03:45:12

The technique you need is called ref count stabilization. You
AddRef yourself before you call back into the client's sink.
Then when the call returns you Release yourself. You must
not have any code accessing your class after the self Release
since you might have been destroyed at this point.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: XXXX@XXXXX.COM
MVP VC FAQ: http://www.yqcomputer.com/
=====================================