CORBA34 — Avoiding RSC/TSC copy on server side

During the interceptor FTF we changed the server-side threading
requirements such that all server-side points run in the same thread
as the ServantManager and servant except receive_request_service_contexts.

We attempted to update 21.4.4.4 "Request Scope vs Thread Scope"
accordingly but knew we screwed the picture and wording up. So we
punted to the RTF.

The main problem with the current wording is that is forces a copy of
of TSC/RSC before the servant manager and then receive_request are
called. This is necessary because 21.4.4.5 item 5 says: "The
receive_request points may modify the RSC, but this no longer affects
the TSC."

The only way to make RSC identical to TSC in receive_request with
respect to reading but also have them be independent with respect to
writing is to make a copy (which could be optimized to copy-on-write,
but why?).

I suggest we just state they are equivalent after
receive_request_service_contexts.

Here is a proposed revision to ptc/00-08-06 along these lines.

Comments?
Harold

21.4.4.4 Request Scope vs Thread Scope

... On the server-side, the request scope PICurrent is attached to
the ServerRequestInfo and follows the request processing. It is
logically equivalent to the thread scope PICurrent after the list of
receive_request_service_contexts interception points are processed.

21.4.4.5 Flow of PICurrent between Scopes

5. The ORB logically makes the RSC equivalent to the server-side TSC
after the receive_request_service_contexts points are processed and
before the servant manager is called. This TSC is within the context
for both the receive_request points, the invocation of the servant
manager, and the invocation of the target operation.

The receive_request points are called. These points have access to the
RSC. Modifying the RSC at this point makes corresponding
modifications on the TSC. Since these points execute in the same
thread as the target operation invocation, these points may modify the
server-side TSC which makes corresponding modifications on the RSC.

6. After the receive_request points are called, control transfers to
the server threads which may also read and write this server-side TSC.
Any modifications to the TSC makes corresponding modifications on the
RSC.

7. <No change>

8. <DELETE THIS ITEM>

9. The send interception points have access to the RSC (and the
equivalent TSC) from which they may populate the reply service context
list. After the invocation result is sent back to the client, the
server-side RSC is logically destroyed.

...

The picture would also need updating, but let's agree on wording first.

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.