[omniORB] thread policy per interface function

[black hole]

Hi,

On 8/17/07, Thomas Lockhart <lockhart at fourpalms.org> wrote:
> > I want part of its functions to be executed single-threaded
> > or multi-threaded (ORB_CTRL_MODEL). But I always want
> > the other part to be executed multi-threaded.
>
> Given your constraints, I would think that protecting some execution
> paths with a mutex held within your server code would give you the
> single-threaded behavior you need. Leave the mutex out for those methods
> which can be executed in parallel.
>
> The downside is that you will be tying up ORB threads while they wait
> for the mutex to become free.

Yes, it is a downside. And there is more to it. Imagine a CORBA
implementation that is not multi-threaded in ORB_CTRL_MODEL[*].
Then I would have to create new threads for the several functions I need.
And this thread-creation would depend on the underlying CORBA
implementation in use.

I understand CORBA specification that there is way to force
a single-threaded POA, but not a multi-threaded one.

Tomas Klacko