[omniORB] Deadlock on recursive invocation with SINGLE_THREAD_MODEL

[Felix Nawothnig]

> omniORB behaves correctly.

Well, I didn't really claim otherwise... but given the choice between an
operation deadlocking and not deadlocking I don't quite see the benefit of
the former.

> ...and the developers think: Avoid SINGLE_THREAD_MODEL, use locks to
> serialize your objects.

When dealing with inherently single-threaded software components that's
hardly sensible. Ignoring the obviously unnecessary boilerplate code (and
lots of places to forget the lock...) for the sake of argument - putting
one giant lock around everything doesn't help avoiding the
recursive-invokation deadlock at all...

Yes, one could use a recursive mutex... not very nice though.

And all that doesn't help when you're dealing with software which expects
(and verifies) that it's being accessed from a single thread. Note that
I'm using such software - and it's not some obscure arcane proprietary
crap but just Qt.

Now you need to marshal every request, along with it's parameters into
that thread and back. That will obviously result in about the same amount
of hand-written boilerplate code as generated by the IDL compiler, after
all you are doing nearly the same thing.

I worked on a project where developers did exactly that (for no apparent
reason though, in their case there was no thread-safety needed .. nor
gained).

About a year after I ripped out the code in question (about 50k lines of
fabulous copy&paste-work) I can laugh about it, but when you have to deal
with code like that it hurts.

Badly.

So _please_ don't tell me do this. ;-)

So, no, SINGLE_THREAD_MODEL does not need to be feared. It has some real
world uses. And my book says this is _exactly_ what it is there for.

Cheers,

Felix