[omniORB] Deadlock on recursive invocation with SINGLE_THREAD_MODEL

[Felix Nawothnig]

>> The reasons are obvious, and it might not be an actual bug (I really
>> don't care what the specs say about this, if anything) but as the ORB
>> could - theoretically - recursively dispatch incoming requests while
>> waiting for an outgoing one to finish I'm wondering what the
>> developers think about this...
> It sounds like you are actually doing a remote call from inside your
> servant, and the remote side calls back?

That's what I meant, yes.

> That definitely can't work. There's no way to know that any incoming
> calls are from the same logical thread of control that was holding the
> lock. It certainly isn't acceptable to allow any incoming call, since
> that would violate the single threading requirement.

Well, it would be enough to just do it for objects served by POAs with
SINGLE_THREAD_MODEL, but I realize that it might not be okay if a
completely unrelated request (on a completely unrelated object served by
the same POA maybe) changes the servant world in-between an outgoing
invokation...

Makes me wish CORBA knew const methods, which could be declared to be
permitted to be called in that case.

My concrete example is:

interface IObserver { string getName(); }
interface ISubject { void registerObserver(IObserver observer); }

My application calls subject->registerObserver(_this()), the subject asks
the observer about it's name and adds it to it's registry (for logging
purposes). Now, it doesn't have to work recursively (i have decoupled it
now), but I kinda liked the idea that the subject first queries the
observer about details before returning from the call.

In another project (where I don't use SINGLE_THREAD_MODEL) I use the same
pattern to do version-checks and the like upon remote registration - and I
couldn't decouple it there (as in case of failure it throws an exception).

Obviously you could always pass the data in the initial registration...
but that'd kinda defeat the purpose, as it's no longer a real
verification.

And that kind of verification does actually serve a few uses (although the
servant can always lie)... for example: In my getName() implementation I
use RTTI to retrieve the actual servant class - if the locator dispatches
to the wrong servant the other side will notice.

Well. I'm just trying to explain that there is a valid reason why I would
want this.

But I understand why it's not being done. :-)

Cheers,

Felix