[omniORB] deactivate_object() in SINGLE_THREADED mode

[Michael Kilburn]

Hi

I have checked mailing list archive and did not find answer to this
question:

for given servant that is registered in POA that works in SINGLE_THREADED
mode -- is it possible to receive more requests after method that calls
deactivate_object() returns? I am looking for two answers:
- from CORBA Standard point of view
- how it is implemented in omniORB v4.0.1 and higher

CORBA standard v2.5 says vaguely that object will be marked as inactive and
removed from the active objects map after all requests ***that arrived
before*** deactivate_object() returns. Which sounds perfectly fine in
ORB_CTRL mode, but vague in case of single threaded mode, because "request
arrival" could be treated differently (i.e. arrived over some connection or
arrived and put into some queue along with addref'ed pointer to servant)

[Duncan Grisby]

Post by Michael Kilburn
for given servant that is registered in POA that works in SINGLE_THREADED
mode -- is it possible to receive more requests after method that calls
- from CORBA Standard point of view
- how it is implemented in omniORB v4.0.1 and higher

In omniORB, calls in single thread policy POAs are held up by a mutex
just before the call into application code, and are therefore considered
already active by the POA. That means that object deactivation will wait
for any calls that arrived before or during the call that provoked the
deactivation.

That's valid according to my reading of the spec, since the calls did
indeed arrive before deactivate_object returned.

Cheers,

Duncan.