re-entrancy pattern issue setbacks

re-entrancy pattern issue setbacks

Post by R2Vvcmd » Sun, 13 Apr 2008 17:27:00

Hello everyone,

Two questions about re-entrancy issue,

1. What is the setback of the issue? I think it is still thread-safe since
only one STA owning thread will execute on STA component;

2. How to avoid it in design?

thanks in advance,

re-entrancy pattern issue setbacks

Post by Igor Tande » Sun, 13 Apr 2008 23:57:10

The problem is that it violates most people's assumptions. When you call
a method, you don't expect any other code to run until the method


void MyMethod() {



You make some changes to an internal data structure, then make a COM
call, then finish your modifications. After this last step, the
structure is in a consistent and usable state. But in the middle, it may
be inconsistent, its invariants violated. Normally, this would not be a
problem - you will restore the invariants before MyMethod returns, and
all other code dealing with this data structure will be happy. But with
reentrancy, some code (even MyMethod itself) may run while the data
structure is halfway through a modification. Most likely, the code
doesn't expect this and would break in interesting ways.

Or consider:

class C {
vector<int> v;

void MyMethod() {
if (!v.empty()) {
v[0] = 42;

This code assumes that if v was not empty before the call, it remains
unchanged afterwards. But some code might have run reentrantly from
inside RemoteCOMCall and modified v.

You can make your code reentrant. This means making sure that all
invariants are restored before making a cross-apartment COM call, and
not expecting data structures to remain unchanged afterwards.

Or, you can implement IMessageFilter and actively prevent reentrancy, by
rejecting incoming COM calls and perhaps some window messages (e.g. user
input that may trigger further processing when you are not ready for
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925


re-entrancy pattern issue setbacks

Post by R2Vvcmd » Mon, 14 Apr 2008 15:59:01

Thanks Igor,

Your reply is great! Just two minor comments,


You mean some other code will break when the data is modified in half-way?
Eg, some inconsistent halfway data will trigger exception in some other code?


"modified v", for example, v.clear()?

regards and have a good weekend,