[omniORB] thread policy per interface function

[Thomas Lockhart]

> 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.

That was prohibited by your "Note2" constraint. And wouldn't this still 
restrict you to serial servicing of requests? You might be able to use 
multiple threads to service a single request, but the ORB will not let 
another request through until that is finished.

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

Forced or not, you know you can get either single- or multi-threaded POAs.

afaicr a POA will handle the entire interface, so having two POAs with 
two servicing models doesn't help. Unless you do something clever with 
having some methods in the multi-threaded POA sending back a forwarding 
request to the client which will redirect the request to the 
single-threaded POA (or vica versa single- to multi-). I haven't done 
that myself so, even if you would accept the overhead of a forwarded 
transaction, having only some methods get forwarded might not be easily 
supported.

hth

                       - Tom