[omniORB] Per process and per object filters

[Duncan Grisby]

On Tuesday 6 April, Frank Lynch wrote:

> > There are no filters in omniORB -- such things are outside the CORBA
> > spec., and are therefore non-portable. 
> 
> I think interceptors are now part of the CORBA spec.
> don't they provide the same functionality as filters - if do they exist in
> omniORB or are there plans to implement them?

Interceptors are an optional part of CORBA 2.2. omniORB is currently a
2.0 implementation, with a few bits from 2.1 and 2.2 (like DynAny). We
do not have any immediate plans to implement interceptors, but the
spec looks quite simple, so it shouldn't be too much work. If someone
wants to contribute an interceptor implementation, we'll happily
integrate it...

> > So, if you just want to be able to call operations of an object
> > concurrently, either from a single client or multiple clients, then
> > omniORB automatically supports it. 
> 
> Question - isen't this *very* dangerous?
> If omniORB by default allows concurrent operation calls on an object then
> all the member variables of the class must be made thread safe in order to
> avoid race conditions! - am I wrong about this?  If this is the case I
> have to modify lots of code.

It's only dangerous if you don't take it into account :-). It's very
simple to enforce single-threaded access to an object by doing:

class Foo_i : public virtual _sk_Foo {
  ...
  omni_mutex mu;
  ...
};

Then at the start of each operation say:

Foo_i::op(...) {
  omni_mutex_lock _l(mu);
  ...
}

The omni_mutex_lock object will automatically release the lock when it
goes out of scope. The only problem you might have with doing this is
if you recursively call operations of your object.

> So its not the case (as in Orbix) that there may be many threads handling
> IIOP requests and these threads then dispatch the request to the main
> thread where the object resides??

No -- one of the things which makes omniORB fast is that there is no
thread switching during the call-chain. The same thread which receives
the incoming request unmarshalls it, calls the relevant implementation
operation, marshalls the result, and sends it back over the network.
This is all explained in chapter 7 of the omniORB user guide.


Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --