Date: Wed, 24 Jan 2001 08:51:38 -0800 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Boldt CC: Polar Humenn , Nick Sharman , interceptors-rtf@omg.org Subject: Re: get_slot, set_slot References: <4.2.0.58.20010124113333.04333ee0@emerald.omg.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ^Dl!!!^W!!L'N!!(?pd9 Juergen, this thread is mostly still a discussion. However, there is an issue that has come out of it: Issue: Clarify that each interception point executes in a distinct logical thread: > > > Polar Humenn: writes: > > > In the Client request interceptor, if I want to communiciate between > > > send_request and receive_reply, regarless, I use PICurrent.set_slot and > > > PICurrent.set_slot to do that, correct? > > Matthew Newhook writes: > > > > Yes, assuming that you've reserved a slot for this purpose (and > > one of > > those set_slot calls above are get_slot :). > Harold Carr writes: > It looks like this was a good question to ask since I do not think that > is possible, so Matthew and I seem to disagree. ptc/00/08/06 21.4.4.6 > paragraph 3 says: > "Interceptors shall assume that each client-side interception point > logically runs in its own thread, with no context relationship > between > it and any other thread. While an ORB implementation may not > actually > behave in this manner, it is up to the ORB implementation to treat > PICurrent as if it did." To me the key word is "EACH" - in other words values set via PICurrent.set_slot in send_request are visible to other interceptors in that point and go into the RSC of client interceptors serving any requests made from within the interceptor(s). However, the TSC for receive_reply (etc) would have a clean PICurrent since it runs in its own logical thread. We should clarify this. ----------------------------------- Date: Wed, 17 Apr 2002 08:27:52 -0700 (PDT) From: Harold Carr To: corba-rtf@omg.org Subject: Proposal for 4173 (interceptors logical thread/point clarification) This is a proposal to resolve Issue 4173: Clarify that each interception point executes in a distinct logical thread (Interceptors) from the list of open issues: http://cgi.omg.org/pub/orbrev/drafts/orb_revision_2002-ytbr.html The last two paragraphs in orbrev/02-02-01 section 21.4.4.6 state: ------------------------- Interceptors shall assume that each client-side interception point logically runs in its own thread, with no context relationship between it and any other thread. While an ORB implementation may not actually behave in this manner, it is up to the ORB implementation to treat PICurrent as if it did. Interceptors shall assume that all server-side interception points except receive_request_service_contexts run in the same thread as the target operation invocation, thereby sharing thread context information. receive_request_service_contexts, like all client-side interception points, logically runs in its own thread, with no context relationship between it and any other thread. ------------------------- The original intent of these paragraphs where to say that all registered interceptors share the same logical thread for each point. This is necessary to avoid infinite mutual recursion when two (or more) interceptors make invocations themselves. If each interceptor instance ran in its own isolated logical thread then it could stop self-recursion during outcalls by setting a flag. But when another interceptor instance at that point executed in its isolated thread and also made outcalls the first interceptor would not see a recursion flag and make another outcall. The same would happen at the second interceptor. If they share the same logical thread then when the first sets its flag and the second makes an outcall, the first can see its flag and therefore not make an additional outcall. To clarify the sharing of logical TSC threads at each interception point I propose changing the last two paragraphs of orbrev/02-02-01 section 21.4.4.6 to: ------------------------- Interceptors shall assume that each client-side interception point logically runs in its own TSC thread, with no context relationship between it and any other thread. For each client-side interception point, a new logical TSC thread is created (i.e., non of its slots are set), all registered ClientRequestInterceptors share that logical TSC thread while they execute in that point, and the logical TSC thread for that point is destroyed at the end of the point. While an ORB implementation may not actually behave in this manner, it is up to the ORB implementation to treat PICurrent as if it did. Interceptors shall assume that all server-side interception points except receive_request_service_contexts run in the same thread as the target operation invocation, thereby sharing thread context information. receive_request_service_contexts, like all client-side interception points, logically runs in its own TSC thread, with no context relationship between it and any other thread. For the receive_request_service_contexts interception point, a new logical TSC thread is created (i.e., non of its slots are set), all registered ServerRequestInterceptors share that logical TSC thread while they execute in that point, and the logical TSC thread for that point is destroyed at the end of the point. While an ORB implementation may not actually behave in this manner, it is up to the ORB implementation to treat PICurrent as if it did. ------------------------- ;; End Date: Wed, 17 Apr 2002 10:21:42 -0700 From: Jonathan Biggar Organization: Floorboard Software X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en To: Harold Carr CC: corba-rtf@omg.org Subject: Re: Proposal for 4173 (interceptors logical thread/point clarification) Harold Carr wrote: > This is a proposal to resolve > > Issue 4173: Clarify that each interception point executes in a > distinct logical thread (Interceptors) > > from the list of open issues: > > http://cgi.omg.org/pub/orbrev/drafts/orb_revision_2002-ytbr.html > > The last two paragraphs in orbrev/02-02-01 section 21.4.4.6 state: Snip. > The original intent of these paragraphs where to say that all > registered interceptors share the same logical thread for each > point. > This is necessary to avoid infinite mutual recursion when two (or > more) interceptors make invocations themselves. > > If each interceptor instance ran in its own isolated logical thread > then it could stop self-recursion during outcalls by setting a flag. > But when another interceptor instance at that point executed in its > isolated thread and also made outcalls the first interceptor would > not > see a recursion flag and make another outcall. The same would > happen > at the second interceptor. > > If they share the same logical thread then when the first sets its > flag and the second makes an outcall, the first can see its flag and > therefore not make an additional outcall. > > To clarify the sharing of logical TSC threads at each interception > point I propose changing the last two paragraphs of orbrev/02-02-01 > section 21.4.4.6 to: This is still pretty difficult to understand. Can we add an example or diagram? -- jon@floorboard.com jon@biggar.org Date: Wed, 17 Apr 2002 17:41:22 +0000 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en To: Jonathan Biggar CC: corba-rtf@omg.org Subject: Re: Proposal for 4173 (interceptors logical thread/point clarification) Hello Jonathan, Jonathan Biggar wrote: > > The original intent of these paragraphs where to say that all > > registered interceptors share the same logical thread for each > > point. > > This is necessary to avoid infinite mutual recursion when two (or > > more) interceptors make invocations themselves. > > > > If each interceptor instance ran in its own isolated logical > > thread > > then it could stop self-recursion during outcalls by setting a > > flag. > > But when another interceptor instance at that point executed in > > its > > isolated thread and also made outcalls the first interceptor would > > not > > see a recursion flag and make another outcall. The same would > > happen > > at the second interceptor. > > > > If they share the same logical thread then when the first sets its > > flag and the second makes an outcall, the first can see its flag > > and > > therefore not make an additional outcall. > > > > To clarify the sharing of logical TSC threads at each interception > > point I propose changing the last two paragraphs of > > orbrev/02-02-01 > > section 21.4.4.6 to: > > This is still pretty difficult to understand. Can we add an example > > or > diagram? A couple of points/questions: * The above is only rationale for the change, not text to be included in the spec. * Do you understand it? * Are you asking for a diagram to be included in the spec? Thanks, H Date: Wed, 17 Apr 2002 11:41:12 -0700 From: Jonathan Biggar Organization: Floorboard Software X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en To: Harold Carr CC: corba-rtf@omg.org Subject: Re: Proposal for 4173 (interceptors logical thread/point clarification) Harold Carr wrote: > > This is still pretty difficult to understand. Can we add an example or > > diagram? > > A couple of points/questions: > > * The above is only rationale for the change, not text to be included in > the spec. I snipped most of the real text just to save space in my message. I don't think that the actual text to be included is understandable. Now it's been a few months since I've looked at the PI spec, so maybe it's just brain rot on my part, but I don't think so. :) > > * Do you understand it? Off the bat, no. I didn't see where the changed text made anything particularly more clear, other than using more specific terminology. The big question mark that I see people wondering about when they read the text is whether this is trying to prescribe a logical thread per request which dispatches all PI callbacks for that request, or whether it is a separate logical thread per registered interceptor. The latter doesn't allow two interceptor implementations to communicate with each other, so I don't think that is the intent. > > * Are you asking for a diagram to be included in the spec? Yes. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 24 Apr 2002 10:27:27 -0700 (PDT) From: Harold Carr To: corba-rtf@omg.org Subject: Issue 4173: each interception point in distinct thread Hello all, Last week I proposed wording to resolve interceptor issue: 4173: Clarify that each interception point executes in a distinct logical thread (Interceptors) Jonathan Biggar thought the wording was unclear and asked for diagrams. I originally brought some of the issues that will surface in the following message to the attention of the interceptor FTF and RTF but no one seemed interested at that time. They are also extremely time-consuming and hard to discuss, particularly in email. However, it looks like we will have to bear that burden, since trying to give the clarification asked by Jonathan makes it necessary to show all the details. The main two points are: 1. orbrev/02-02-01 section 21.4.4.2 gives a non-normative example which shows how to avoid recursion when making outcalls from interceptors. The example only works if only one registered interceptor makes an outcall. If two or more interceptors make outcalls then infinite recursion results. 2. To avoid infinite recursion when two or more interceptors make outcalls requires that all interceptor instances at each point execute in the same logical thread. That condition is specified by orbrev/02-02-01 section 21.4.4.6. Issue 4173 asks for further clarification. Detail: The diagrams below show: 1st diagram: What happens if the example code in 21.4.4.2 is used for two or more interceptors making outcalls. 2nd diagram: A way to solve the recusion problem which depends on section 21.4.4.6. You will need to view it in a fixed width font with a wide screen. (Note: I am note suggesting these diagrams be included in the spec. They are provided to help understand the issue.) LEGEND: tN ; (logical) thread N N : sequence order foo.bar : original invocation in client code A, B, C : client interceptors sr : send_request ri.gs : RequestInfo.get_slot pic.ss : PICurrent.set_slot A.a : outcall from interceptor A (not a call to itself) B.b : outcall from interceptor B T : true As shown in orbrev/02-02-01 section 21.4.4.2: If an interceptor only sets its pic recursion flag and does the recursive call if its ri recurse slot!=T then infinite recursion if 2 or more interceptors make outcalls. t1 | t2 | t3 | t4 | t5 | t6 | foo.bar | A.a | B.b | A.a' | B.b' 1 foo.bar|2 A.sr |3 A.sr |5 A.sr |6 A.sr |12 A.sr | ri.gs(A)!=T| ri.gs(A)==T| ri.gs(A)!=T| ri.gs(A)==T| ri.gs(A)!=T | pic.ss(A,T) | | pic.ss(A,T) | | pic.ss(A,T) | A.a | | A.a' | | A.a'' ... | | | | | | | | |7 B.sr | | |4 B.sr | | ri.gs(B)!=T | | ri.gs(B)!=T| | pic.ss(B,T) | | pic.ss(B,T) | | B.b' | | B.b | | ------------------------------------------------------------------------------ If an interceptor only does the recursive call if its recurse slot!=T but always sets that slot to T on each recursion then no infinite recusion. That "always setting" (marked "*" below the first time it occurs) is a key usage tip. The example in the specification should be updated accordingly. For recursion to terminate all interceptor instances at each interception point must run in the same logical thread as stated in orbrev/02-02-01 section 21.4.4.6. However, is it right for A not to do anything for the B.b call which isn't the foo.bar call? And note that some interceptors service other interceptor's calls depending on registration order (i.e., B.sr services A.a but A.sr does not service B.b). t1 | t2 | t3 | t4 | t5 | t6 | t7 | t8 | foo.bar | A.a | B.b | C.c | C.c' | B.b' | C.c'' 1 foo.bar|2 A.sr |3 A.sr |5 A.sr |8 A.sr |12 A.sr |16 A.sr |19 A.sr | ri.gs(A)!=T| ri.gs(A)==T| ri.gs(A)==T| ri.gs(A)==T| ri.gs(A)==T| ri.gs(A)==T| ri.gs(A)==T | pic.ss(A,T) | pic.ss(A,T)*| pic.ss(A,T) | pic.ss(A,T) | pic.ss(A,T) | pic.ss(A,T) | pic.ss(A,T) | A.a | | | | | | | |4 B.sr |6 B.sr |9 B.sr |13 B.sr |17 B.sr |20 B.sr | | ri.gs(B)!=T| ri.gs(B)==T| ri.gs(B)==T| ri.gs(B)==T| ri.gs(B)==T| ri.gs(B)==T | | pic.ss(B,T) | pic.ss(B,T) | pic.ss(B,T) | pic.ss(B,T) | pic.ss(B,T) | pic.ss(B,T) | | B.b | | | | | | | | | | | |21 C.sr | |11 C.sr |7 C.sr |10 C.sr |14 C.sr |18 C.sr | ri.gs(C)==T | | ri.gs(C)!=T| ri.gs(C)!=T| ri.gs(C)==T| ri.gs(C)==T| ri.gs(C)!=T| pic.ss(C,T) | | pic.ss(C,T) | pic.ss(C,T) | pic.ss(C,T) | pic.ss(C,T) | pic.ss(C,T) | | | C.c' | C.c | | | C.c'' | | | | | | |15 B.sr | | | | | ri.gs(B)!=T| | | | | pic.ss(B,T) | | | | | B.b' | | | | | | | | | |22 C.sr | | | | | ri.gs(C)!=T| | | | | pic.ss(C,T) | | | | | C.c''' - t9 (not shown) finds all T so no action and you are finally done. Date: Mon, 6 May 2002 07:44:35 -0700 (PDT) From: Harold Carr To: corba-rtf@omg.org Cc: corba-dev@sun.com Subject: Proposed resolution to Issue 4173: interception point/TSC This is a proposal to resolve Issue 4173: Clarify that each interception point executes in a distinct logical thread (Interceptors) from the list of open issues: http://cgi.omg.org/pub/orbrev/drafts/orb_revision_2002-ytbr.html The last two paragraphs in orbrev/02-02-01 section 21.4.4.6 state: ------------------------- Interceptors shall assume that each client-side interception point logically runs in its own thread, with no context relationship between it and any other thread. While an ORB implementation may not actually behave in this manner, it is up to the ORB implementation to treat PICurrent as if it did. Interceptors shall assume that all server-side interception points except receive_request_service_contexts run in the same thread as the target operation invocation, thereby sharing thread context information. receive_request_service_contexts, like all client-side interception points, logically runs in its own thread, with no context relationship between it and any other thread. ------------------------- To clarify the sharing of logical TSC threads at each interception point I propose changing the last two paragraphs of orbrev/02-02-01 section 21.4.4.6 to: ------------------------- Interceptors shall assume that each client-side interception point logically runs in its own TSC thread, with no context relationship between it and any other thread. Each point's logical TSC thread is shared by all registered ClientRequestInterceptors executing in that point. While an ORB implementation may not actually behave in this manner, it is up to the ORB implementation to treat PICurrent as if it did. Interceptors shall assume that all server-side interception points except receive_request_service_contexts run in the same thread as the target operation invocation, thereby sharing thread context information. receive_request_service_contexts, like all client-side interception points, logically runs in its own TSC thread, with no context relationship between it and any other thread. The receive_request_service_contexts interception point logical TSC thread is shared by all registered ServerRequestInterceptors executing in that point. While an ORB implementation may not actually behave in this manner, it is up to the ORB implementation to treat PICurrent as if it did. Cheers, Harold X-Sender: beckwb@192.168.10.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 07 May 2002 22:27:00 -0400 To: Harold Carr From: Bill Beckwith Subject: Re: Proposed resolution to Issue 4173: interception point/TSC Cc: corba-rtf@omg.org, corba-dev@sun.com At 10:44 AM 5/6/2002, Harold Carr wrote: >The last two paragraphs in orbrev/02-02-01 section 21.4.4.6 state: > >------------------------- >Interceptors shall assume that each client-side interception point >logically runs in its own thread, with no context relationship >between >it and any other thread. While an ORB implementation may not actually >behave in this manner, it is up to the ORB implementation to treat >PICurrent as if it did. > >Interceptors shall assume that all server-side interception points >except receive_request_service_contexts run in the same thread as the >target operation invocation, thereby sharing thread context >information. receive_request_service_contexts, like all client-side >interception points, logically runs in its own thread, with no >context >relationship between it and any other thread. >------------------------- > >To clarify the sharing of logical TSC threads at each interception >point I propose changing the last two paragraphs of orbrev/02-02-01 >section 21.4.4.6 to: The problem with the text below is that it is not clear on what specific behaviors you want to prevent (if any) and which specific behaviors you want to require. IMO it is appropriate for the specification to talk about what the application programmer can rely upon. It is not appropriate to make general statements about ORBs should "treat PICurrent". I just looking for the text to be much more explicit and clear. Then I can figure out if I support or disagree with the semantics described in that text. "it is up to the ORB implementation to treat PICurrent as if it did" just isn't clear as to what the ORB is supposed to do and prevent. Sorry for the grumbling, its late. Bill >------------------------- > >Interceptors shall assume that each client-side interception point >logically runs in its own TSC thread, with no context relationship >between it and any other thread. Each point's logical TSC thread is >shared by all registered ClientRequestInterceptors executing in that >point. While an ORB implementation may not actually behave in this >manner, it is up to the ORB implementation to treat PICurrent as if it >did. > >Interceptors shall assume that all server-side interception points >except receive_request_service_contexts run in the same thread as the >target operation invocation, thereby sharing thread context >information. receive_request_service_contexts, like all client-side >interception points, logically runs in its own TSC thread, with no >context relationship between it and any other thread. The >receive_request_service_contexts interception point logical TSC thread >is shared by all registered ServerRequestInterceptors executing in >that point. While an ORB implementation may not actually behave in >this manner, it is up to the ORB implementation to treat PICurrent as >if it did. > >Cheers, >Harold Date: Wed, 08 May 2002 19:59:13 +0000 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en To: Bill Beckwith CC: corba-rtf@omg.org, corba-dev@sun.com Subject: Re: Proposed resolution to Issue 4173: interception point/TSC Hello Bill, > > "it is up to the ORB implementation to treat PICurrent as if it did" > just isn't clear as to what the ORB is supposed to do and prevent. The text you quote is from the existing spec. The only thing I am suggesting adding is: > > Each point's logical TSC thread is > >shared by all registered ClientRequestInterceptors executing in > >that > >point. I sent out mail a week or so ago giving VERY detailed reasons why this is a good thing. In fact, I think it is the intent of the spec. The addition I propose is to just make it a little more clear. Cheers, H X-Sender: beckwb@192.168.10.3 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 08 May 2002 18:55:03 -0400 To: Harold Carr From: Bill Beckwith Subject: Re: Proposed resolution to Issue 4173: interception point/TSC Cc: corba-rtf@omg.org, corba-dev@sun.com At 03:59 PM 5/8/2002, Harold Carr wrote: >Hello Bill, > >> >> "it is up to the ORB implementation to treat PICurrent as if it >did" >> just isn't clear as to what the ORB is supposed to do and prevent. > >The text you quote is from the existing spec. Oh. Sorry. That text is virtually meaningless. Let's fix it. >The only thing I am >suggesting adding is: > >> > Each point's logical TSC thread is >> >shared by all registered ClientRequestInterceptors executing in >that >> >point. > >I sent out mail a week or so ago giving VERY detailed reasons why >this >is a good thing. In fact, I think it is the intent of the spec. The >addition I propose is to just make it a little more clear. Yes, it is very nice for different interceptors to pass data to each other. No objection to what you want (if I understand it). Does the text already define what TSC means? Bill Date: Wed, 08 May 2002 23:28:23 +0000 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en To: Bill Beckwith CC: corba-rtf@omg.org, corba-dev@sun.com Subject: Re: Proposed resolution to Issue 4173: interception point/TSC Hello Bill, Bill Beckwith wrote: > >> "it is up to the ORB implementation to treat PICurrent as if it did" > >> just isn't clear as to what the ORB is supposed to do and prevent. > > > >The text you quote is from the existing spec. > > Oh. Sorry. That text is virtually meaningless. Let's fix it. Would you be interested in providing some alternate wording? > Does the text already define what TSC means? Yes. Cheers, H X-Sender: beckwb@192.168.10.3 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 09 May 2002 09:26:41 -0400 To: Harold Carr From: Bill Beckwith Subject: Re: Proposed resolution to Issue 4173: interception point/TSC Cc: corba-rtf@omg.org, corba-dev@sun.com At 07:28 PM 5/8/2002, Harold Carr wrote: >Hello Bill, > >Bill Beckwith wrote: > >> >> "it is up to the ORB implementation to treat PICurrent as if it did" >> >> just isn't clear as to what the ORB is supposed to do and prevent. >> > >> >The text you quote is from the existing spec. >> >> Oh. Sorry. That text is virtually meaningless. Let's fix it. > >Would you be interested in providing some alternate wording? Yea, I'll take a crack at it. I'll write something clear that is based on what I think the text is implying. We'll see if it matches everybody else's interpretation... Bill Date: Wed, 15 May 2002 15:41:43 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: corba-rtf@omg.org Subject: Proposed resolution for 4173 The following resolution will appear in the next vote unless there is significant technical objection to it. Jishnu. ____________________________________________________________________ Issue 4173: Clarify that each interception point executes in a distinct logical thread (interceptors-rtf) http://cgi.omg.org/issues/issue4173.txt Source: Syracuse University (Mr. Polar Humenn, polar@adiron.com) Nature: Uncategorized Issue Severity: Summary: To me the key word is "EACH" - in other words values set via PICurrent.set_slot in send_request are visible to other interceptors in that point and go into the RSC of client interceptors serving any requests made from within the interceptor(s). However, the TSC for receive_reply (etc) would have a clean PICurrent since it runs in its own logical thread. We should clarify this. Resolution: Clarify as shown below Revised Text: The last two paragraphs in orbrev/02-02-01 section 21.4.4.6 state: ------------------------- "Interceptors shall assume that each client-side interception point logically runs in its own thread, with no context relationship between it and any other thread. While an ORB implementation may not actually behave in this manner, it is up to the ORB implementation to treat PICurrent as if it did. Interceptors shall assume that all server-side interception points except receive_request_service_contexts run in the same thread as the target operation invocation, thereby sharing thread context information. receive_request_service_contexts, like all client-side interception points, logically runs in its own thread, with no context relationship between it and any other thread." ------------------------- To clarify the sharing of logical TSC threads at each interception point change the last two paragraphs of orbrev/02-02-01 section 21.4.4.6 to (the changes shown bracketed between *s): "Interceptors shall assume that each client-side interception point logically runs in its own TSC thread, with no context relationship between it and any other thread. *Each point's logical TSC thread is shared by all registered ClientRequestInterceptors executing in that point.* While an ORB implementation may not actually behave in this manner, it is up to the ORB implementation to treat PICurrent as if it did. Interceptors shall assume that all server-side interception points except receive_request_service_contexts run in the same thread as the target operation invocation, thereby sharing thread context information. receive_request_service_contexts, like all client-side interception points, logically runs in its own TSC thread, with no context relationship between it and any other thread. *The receive_request_service_contexts interception point logical TSC thread is shared by all registered ServerRequestInterceptors executing in that point. While an ORB implementation may not actually behave in this manner, it is up to the ORB implementation to treat PICurrent as if it did.*" Actions taken: Incorporate changes and close issue.