Issue 4155: MAIN_THREAD_MODEL questions (firewall-traversal-ftf) Source: Borland Software Corporation (Mr. Andy Cutright, nobody) Nature: Uncategorized Issue Severity: Summary: i have a few questions about the POA ThreadPolicy type MAIN_THREAD_MODEL. first, the 2.4.1 spec (00-11-03), sec 4.2.3.2 , 'perform_work' states, "If called by the main thread, this operation performs an implementation-defined unit of work; otherwise it does nothing." how is a distinguished main thread supposed to be reliably determined? i'm not sure we really need to define this. i'd think what we're trying to say is that the thread that calls perform_work() is the thread that will be used to do the work, and it is up to the application to make sure this happens. in section 4.2.3.3, the spec states, "For maximum portability an application should call either run or perform_work on its main thread." to me it seems the intent is to let the application determine what the 'main thread' is. second, what happens if an application calls both run & perform_work? and what happens if the application calls run from multiple threads? it isn't really clear what the difference in request handling with regard to the thread used is between run() & perform_work(). right now the spec seems to imply through the use of the message loop example in section 4.2.3.2 that perform_work is really intended to be used to handle situations where a single thread must be used for _all_ application activity. now add to that the note on pg 11-12 about using the main thread model: "Note - Not all environments have such a special requirement. If not, while requests will be processessed sequentially, they may not all be processed on the same thread." my interpretation is that ORB::run would be used in cases where you simply want the POAs to be accessed sequentially, but the application doesn't care about which thread the implementation uses, but you would need to call perform_work to specifically hand the application defined main thread to process requests. my suggestion (finally ;^) is that we should state perform_work should be called, on whichever thread the application likes, if it wants to hand a specific thread to the ORB to do work. otherwise, calling ORB::run from any thread simply means the implementation is free to handle requests for servants associated with main thread model POAs on whatever thread the implementation may choose (including a new one), in keeping with the requirement that the requests be processed on each POA's servants sequentially.. one more question: does it make sense to state that a callback type of architecture won't work when using this threading model? Resolution: Revised Text: Actions taken: January 17, 2001: received issue November 5, 2002: moved from core to Firewall April 28, 2003: closed issue October 6, 2003: reopened issue Discussion: Resolution: The discussion in the archive suggests that it is not possible to arrive at a consensus on making any of these changes that do not break at least some deployed systems and the gains from making the change don't appear to justify the making of the change. Close no change. End of Annotations:===== Date: Wed, 17 Jan 2001 19:34:45 -0800 From: "Andy Cutright" X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: orb_revision@omg.org Subject: MAIN_THREAD_MODEL questions Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: &13e9(W1!!bM$!!?8Z!! hi all, i have a few questions about the POA ThreadPolicy type MAIN_THREAD_MODEL. first, the 2.4.1 spec (00-11-03), sec 4.2.3.2 , 'perform_work' states, "If called by the main thread, this operation performs an implementation-defined unit of work; otherwise it does nothing." how is a distinguished main thread supposed to be reliably determined? i'm not sure we really need to define this. i'd think what we're trying to say is that the thread that calls perform_work() is the thread that will be used to do the work, and it is up to the application to make sure this happens. in section 4.2.3.3, the spec states, "For maximum portability an application should call either run or perform_work on its main thread." to me it seems the intent is to let the application determine what the 'main thread' is. second, what happens if an application calls both run & perform_work? and what happens if the application calls run from multiple threads? it isn't really clear what the difference in request handling with regard to the thread used is between run() & perform_work(). right now the spec seems to imply through the use of the message loop example in section 4.2.3.2 that perform_work is really intended to be used to handle situations where a single thread must be used for _all_ application activity. now add to that the note on pg 11-12 about using the main thread model: "Note - Not all environments have such a special requirement. If not, while requests will be processessed sequentially, they may not all be processed on the same thread." my interpretation is that ORB::run would be used in cases where you simply want the POAs to be accessed sequentially, but the application doesn't care about which thread the implementation uses, but you would need to call perform_work to specifically hand the application defined main thread to process requests. my suggestion (finally ;^) is that we should state perform_work should be called, on whichever thread the application likes, if it wants to hand a specific thread to the ORB to do work. otherwise, calling ORB::run from any thread simply means the implementation is free to handle requests for servants associated with main thread model POAs on whatever thread the implementation may choose (including a new one), in keeping with the requirement that the requests be processed on each POA's servants sequentially.. one more question: does it make sense to state that a callback type of architecture won't work when using this threading model? cheers, andy cutright officially of inprise pretty soon of borland ;^) Sender: jon@corvette.floorboard.com Message-ID: <3A666E6F.D58F546@floorboard.com> Date: Wed, 17 Jan 2001 20:17:51 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Andy Cutright CC: orb_revision@omg.org Subject: Re: MAIN_THREAD_MODEL questions References: <3A666455.54E28B8D@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: EI/!!'6$e9]P~!!ePEe9 Andy Cutright wrote: > > hi all, > > i have a few questions about the POA ThreadPolicy type > MAIN_THREAD_MODEL. > > first, the 2.4.1 spec (00-11-03), sec 4.2.3.2 , 'perform_work' states, > "If called by the main thread, this operation performs an > implementation-defined unit of work; otherwise it does nothing." > > how is a distinguished main thread supposed to be reliably determined? > i'm not sure we really need to define this. i'd think what we're trying > to say is that the thread that calls perform_work() is the thread that > will be used to do the work, and it is up to the application to make > sure this happens. in section 4.2.3.3, the spec states, > "For maximum portability an application should call either run or > perform_work on its main thread." > > to me it seems the intent is to let the application determine what the > 'main thread' is. There's some context that you may be missing. There are some run-time environments where code must be executed in the "main" thread to operate correctly. An example would be a library compiled in single threaded-mode that, because you don't have the source code, must be linked as-is with a multi-threaded application. In that environment, only the initial thread (the one that invokes main() in C or C++) will execute the library code correctly. Ultimately, it is up to the ORB implementation (in concert with the language runtime environment to define what the term "main thread" means and whether it needs special handling. > second, what happens if an application calls both run & perform_work? > and what happens if the application calls run from multiple threads? it > isn't really clear what the difference in request handling with regard > to the thread used is between run() & perform_work(). The result is implementation specific. In an environment where there is a distinguished "main thread", this is almost certainly an error. The intent of MAIN_THREAD_MODEL is only one thread to call run() or perform_work(), and that thread is the one to service POAS with MAIN_THREAD_MODEL. Other POAs with other threading models can coexist, and may or may not use the main thread as well. > right now the spec seems to imply through the use of the message loop > example in section 4.2.3.2 that perform_work is really intended to be > used to handle situations where a single thread must be used for _all_ > application activity. now add to that the note on pg 11-12 about using > the main thread model: > "Note - Not all environments have such a special requirement. If > not, while requests will be processessed sequentially, they may not all > be processed on the same thread." > > my interpretation is that ORB::run would be used in cases where you > simply want the POAs to be accessed sequentially, but the application > doesn't care about which thread the implementation uses, but you would > need to call perform_work to specifically hand the application defined > main thread to process requests. > > my suggestion (finally ;^) is that we should state perform_work should > be called, on whichever thread the application likes, if it wants to > hand a specific thread to the ORB to do work. otherwise, calling > ORB::run from any thread simply means the implementation is free to > handle requests for servants associated with main thread model POAs on > whatever thread the implementation may choose (including a new one), in > keeping > with the requirement that the requests be processed on each POA's > servants sequentially.. I'll have to disagree. What you describe is what SINGLE_THREAD_MODEL does. > one more question: does it make sense to state that a callback type of > architecture won't work when using this threading model? No, since it might actually work, depending on the application and the programming environment. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 18 Jan 2001 11:50:09 -0800 From: "Andy Cutright" X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar CC: Andy Cutright , orb_revision@omg.org Subject: Re: MAIN_THREAD_MODEL questions References: <3A666455.54E28B8D@inprise.com> <3A666E6F.D58F546@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: X&9!!2VB!!F'#!!;3g!! hi jonathon, comments inlined.. Jonathan Biggar wrote: > Andy Cutright wrote: > > > > hi all, > > > > i have a few questions about the POA ThreadPolicy type > > MAIN_THREAD_MODEL. > > > > first, the 2.4.1 spec (00-11-03), sec 4.2.3.2 , 'perform_work' states, > > "If called by the main thread, this operation performs an > > implementation-defined unit of work; otherwise it does nothing." > > > > how is a distinguished main thread supposed to be reliably determined? > /// elided.. > > There's some context that you may be missing. There are some >run-time > environments where code must be executed in the "main" thread to >operate > correctly. An example would be a library compiled in single > threaded-mode that, because you don't have the source code, must be > linked as-is with a multi-threaded application. In that >environment, > only the initial thread (the one that invokes main() in C or C++) >will > execute the library code correctly. > > Ultimately, it is up to the ORB implementation (in concert with the > language runtime environment to define what the term "main thread" >means > and whether it needs special handling. i'm aware of this context, but i'd prefer that we leave the burden on the application developer to make sure they call the function from the appropriate thread, rather than stating 'for maximum portability an application should..'. > > > > second, what happens if an application calls both run & >perform_work? > > and what happens if the application calls run from multiple >threads? it > > isn't really clear what the difference in request handling with >regard > > to the thread used is between run() & perform_work(). > > The result is implementation specific. In an environment where >there is > a distinguished "main thread", this is almost certainly an error. >The > intent of MAIN_THREAD_MODEL is only one thread to call run() or > perform_work(), and that thread is the one to service POAS with > MAIN_THREAD_MODEL. Other POAs with other threading models can >coexist, > and may or may not use the main thread as well. i agree that the end result of calling both run() & perform_work() should be implementation specific, and i'd like to see language added to the spec to make that point. > > > > right now the spec seems to imply through the use of the message >loop > > example in section 4.2.3.2 that perform_work is really intended to >be > > used to handle situations where a single thread must be used for >_all_ > > application activity. now add to that the note on pg 11-12 about >using > > the main thread model: > > "Note - Not all environments have such a special >requirement. If > > not, while requests will be processessed sequentially, they may >not all > > be processed on the same thread." > > > > my interpretation is that ORB::run would be used in cases where >you > > simply want the POAs to be accessed sequentially, but the >application > > doesn't care about which thread the implementation uses, but you >would > > need to call perform_work to specifically hand the application >defined > > main thread to process requests. > > > > my suggestion (finally ;^) is that we should state perform_work >should > > be called, on whichever thread the application likes, if it wants >to > > hand a specific thread to the ORB to do work. otherwise, calling > > ORB::run from any thread simply means the implementation is free >to > > handle requests for servants associated with main thread model >POAs on > > whatever thread the implementation may choose (including a new >one), in > > keeping > > with the requirement that the requests be processed on each POA's > > servants sequentially.. > > I'll have to disagree. What you describe is what >SINGLE_THREAD_MODEL > does. the single thread model doesn't make any guarantees about request processing across multiple POAs. also, the note that i've mentioned specifically says that some usages of the main thread model may result in multiple threads being used to handle request on any given set of main thread model POAs. so the distinction between the main thread model and the single thread model isn't clear at that point. why have a main thread model, and then state in some environments (which itself isn't specified) that the implementation may use different threads to handle requests? the spec was changed from 2.3 to 2.4 such that some of the lanuage that was used in 2.3 to describe the single thread model is used in 2.4 to describe the main thread model. i think we should push further to state the main thread model guarantees in all cases that if the application calls run() or perform_work() that thread of execution will be used to process requests. we can do away with my earlier proposal to allow ORB::run() to mean that the implementation is free to handle requests for main thread model with any thread in this case. > > > > one more question: does it make sense to state that a callback >type of > > architecture won't work when using this threading model? > > No, since it might actually work, depending on the application and >the > programming environment. if you have only a single thread with which to do work, how are you going to guarantee, without using threading primitive, that you aren't going to get reentrant behavior? or is that the application's responsibility? > > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org cheers, andy Date: Thu, 18 Jan 2001 15:44:14 -0500 From: Paul Kyzivat X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: orb_revision@omg.org Subject: Re: MAIN_THREAD_MODEL questions References: <3A666455.54E28B8D@inprise.com> <3A666E6F.D58F546@floorboard.com> <3A6748F1.1D1F8A16@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Ldad9YLMd9Dn2!!S17!! comments inline below. Paul Andy Cutright wrote: > > i'm aware of this context, but i'd prefer that we leave the burden on the > application developer to make sure they call the function from the > appropriate thread, rather than stating 'for maximum portability an > application should..'. I believe this would be a very unfriendly thing to do, and would break lots of user code. My interpretation is that you can call run from whatever thread(s) you like. The orb is then free to decide which (if any) of them is the "main thread" and use it to do work. For any others, the orb is supposed to block the thread until shutdown. Of course, this still leaves a portability problem. If, in a particular implementation, there is a distinguished "main thread", and the user never calls run from that thread, the application may not work. I don't see any good solution to that. > > > > > > > > second, what happens if an application calls both run & perform_work? > > > and what happens if the application calls run from multiple threads? it > > > isn't really clear what the difference in request handling with regard > > > to the thread used is between run() & perform_work(). > > > > The result is implementation specific. In an environment where there is > > a distinguished "main thread", this is almost certainly an error. The > > intent of MAIN_THREAD_MODEL is only one thread to call run() or > > perform_work(), and that thread is the one to service POAS with > > MAIN_THREAD_MODEL. Other POAs with other threading models can coexist, > > and may or may not use the main thread as well. > > i agree that the end result of calling both run() & perform_work() should be > implementation specific, and i'd like to see language added to the spec to > make that point. I don't see why this should be any more implementation specific than doing either of these alone in a single thread is. If there is a distinguished main thread, then at most one of these can be it. The behavior for each is defined in isolation, and they don't ever conflict. If there is no distinguished main thread, then the orb is free to choose one or the other (or neither) as the main thread. Again, once this is done the behavior is well defined. Bottom line - no new issues are introduced by actions in a second thread. > > > > > > > > right now the spec seems to imply through the use of the message loop > > > example in section 4.2.3.2 that perform_work is really intended to be > > > used to handle situations where a single thread must be used for _all_ > > > application activity. now add to that the note on pg 11-12 about using > > > the main thread model: > > > "Note - Not all environments have such a special requirement. If > > > not, while requests will be processessed sequentially, they may not all > > > be processed on the same thread." > > > > > > my interpretation is that ORB::run would be used in cases where you > > > simply want the POAs to be accessed sequentially, but the application > > > doesn't care about which thread the implementation uses, but you would > > > need to call perform_work to specifically hand the application defined > > > main thread to process requests. > > > > > > my suggestion (finally ;^) is that we should state perform_work should > > > be called, on whichever thread the application likes, if it wants to > > > hand a specific thread to the ORB to do work. otherwise, calling > > > ORB::run from any thread simply means the implementation is free to > > > handle requests for servants associated with main thread model POAs on > > > whatever thread the implementation may choose (including a new one), in > > > keeping > > > with the requirement that the requests be processed on each POA's > > > servants sequentially.. > > > > I'll have to disagree. What you describe is what SINGLE_THREAD_MODEL > > does. > > the single thread model doesn't make any guarantees about request processing > across multiple POAs. also, the note that i've mentioned specifically says > that some usages of the main thread model may result in multiple threads > being used to handle request on any given set of main thread model POAs. so > the distinction between the main thread model and the single thread model > isn't clear at that point. why have a main thread model, and then state in > some environments (which itself isn't specified) that the implementation may > use different threads to handle requests? the spec was changed from 2.3 to > 2.4 such that some of the lanuage that was used in 2.3 to describe the single > thread model is used in 2.4 to describe the main thread model. i think we > should push further to state the main thread model guarantees in all cases > that if the application calls run() or perform_work() that thread of > execution will be used to process requests. we can do away with my earlier > proposal to allow ORB::run() to mean that the implementation is free to > handle requests for main thread model with any thread in this case. My take is that run, or perform_work, is there simply to *offer* a thread to the orb. Then the orb can choose to use it or not. In and of itself this should not imply anything about synchrony of request processing or what thread anything runs on. Date: Thu, 18 Jan 2001 13:03:24 -0800 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: orb_revision@omg.org Subject: Re: MAIN_THREAD_MODEL questions References: <3A666455.54E28B8D@inprise.com> <3A666E6F.D58F546@floorboard.com> <3A6748F1.1D1F8A16@inprise.com> <3A67559E.E4502A26@cisco.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: KQO!!Hb~!!i!ed9\_`d9 Hi Paul, comments inline.... Paul Kyzivat wrote: > comments inline below. > > Paul > > Andy Cutright wrote: > > > > i'm aware of this context, but i'd prefer that we leave the burden >on the > > application developer to make sure they call the function from the > > appropriate thread, rather than stating 'for maximum portability >an > > application should..'. > > I believe this would be a very unfriendly thing to do, and would > break lots of user code. > > My interpretation is that you can call run from whatever thread(s) > you like. The orb is then free to decide which (if any) of them is > the "main thread" and use it to do work. For any others, the orb is > supposed to block the thread until shutdown. > > Of course, this still leaves a portability problem. If, in a >particular > implementation, there is a distinguished "main thread", and the user > never calls run from that thread, the application may not work. > I don't see any good solution to that. I agree. This would be application error. However, the converse is where things get a little interesting. What happens if the application calls run/perform work from more than one thread? More specifically what thread does all POAs with the MAIN_THREAD_MODEL execute their requests in? > > > > second, what happens if an application calls both run & perform_work? > > > > and what happens if the application calls run from multiple threads? it > > > > isn't really clear what the difference in request handling with regard > > > > to the thread used is between run() & perform_work(). > > > > > > The result is implementation specific. In an environment where there is > > > a distinguished "main thread", this is almost certainly an error. The > > > intent of MAIN_THREAD_MODEL is only one thread to call run() or > > > perform_work(), and that thread is the one to service POAS with > > > MAIN_THREAD_MODEL. Other POAs with other threading models can coexist, > > > and may or may not use the main thread as well. > > > > i agree that the end result of calling both run() & perform_work() should be > > implementation specific, and i'd like to see language added to the spec to > > make that point. > > I don't see why this should be any more implementation specific than > doing either of these alone in a single thread is. > > If there is a distinguished main thread, then at most one of these can > be it. > The behavior for each is defined in isolation, and they don't ever > conflict. With POAs that have MAIN_THREAD_MODEL, it would be necessary to locate that "distinguished" main thread, right? > If there is no distinguished main thread, then the orb is free to choose > one or the other (or neither) as the main thread. Again, once this is > done > the behavior is well defined. Again how does the ORB know that there is or isn't a "distinguished" main thread (in the context of multiple threads calling run). > Bottom line - no new issues are introduced by actions in a second > thread. > > > > > > > > > > > > > right now the spec seems to imply through the use of the > message loop > > > > example in section 4.2.3.2 that perform_work is really > intended to be > > > > used to handle situations where a single thread must be used > for _all_ > > > > application activity. now add to that the note on pg 11-12 > about using > > > > the main thread model: > > > > "Note - Not all environments have such a special > requirement. If > > > > not, while requests will be processessed sequentially, they > may not all > > > > be processed on the same thread." > > > > > > > > my interpretation is that ORB::run would be used in cases > where you > > > > simply want the POAs to be accessed sequentially, but the > application > > > > doesn't care about which thread the implementation uses, but > you would > > > > need to call perform_work to specifically hand the application > defined > > > > main thread to process requests. > > > > > > > > my suggestion (finally ;^) is that we should state > perform_work should > > > > be called, on whichever thread the application likes, if it > wants to > > > > hand a specific thread to the ORB to do work. otherwise, > calling > > > > ORB::run from any thread simply means the implementation is > free to > > > > handle requests for servants associated with main thread model > POAs on > > > > whatever thread the implementation may choose (including a new > one), in > > > > keeping > > > > with the requirement that the requests be processed on each > POA's > > > > servants sequentially.. > > > > > > I'll have to disagree. What you describe is what > SINGLE_THREAD_MODEL > > > does. > > > > the single thread model doesn't make any guarantees about request > processing > > across multiple POAs. also, the note that i've mentioned > specifically says > > that some usages of the main thread model may result in multiple > threads > > being used to handle request on any given set of main thread model > POAs. so > > the distinction between the main thread model and the single > thread model > > isn't clear at that point. why have a main thread model, and then > state in > > some environments (which itself isn't specified) that the > implementation may > > use different threads to handle requests? the spec was changed > from 2.3 to > > 2.4 such that some of the lanuage that was used in 2.3 to describe > the single > > thread model is used in 2.4 to describe the main thread model. i > think we > > should push further to state the main thread model guarantees in > all cases > > that if the application calls run() or perform_work() that thread > of > > execution will be used to process requests. we can do away with my > earlier > > proposal to allow ORB::run() to mean that the implementation is > free to > > handle requests for main thread model with any thread in this > case. > > My take is that run, or perform_work, is there simply to *offer* a > thread to the > orb. Then the orb can choose to use it or not. In and of itself this > should not > imply anything about synchrony of request processing or what thread > anything runs on. I am afraid I have to disagree. I agree that in the absence of the MAIN_THREAD_MODEL, what you say is correct, but in the case of the MAIN_THREAD_MODEL it is necessary to determine what happens. The ORB has to choose in this case. Not choosing it will totally break portability. Let's take a scenario. I have a POA with MAIN_THREAD_MODEL and I call ORB.run on only one thread. If ORBs have the freedom to not use it, then how am I guaranteed the MAIN_THREAD_MODEL behavior expected. Second scenario: I have two POA with MAIN_THREAD_MODEL and I call ORB.run in multiple threads. Is the ORB free to use any thread to dispatch requests as long as they are serialized across all the MAIN_THREAD_MODEL poas? Vijay Date: Thu, 18 Jan 2001 16:39:29 -0500 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijaykumar Natarajan CC: Paul Kyzivat , orb_revision@omg.org Subject: Re: MAIN_THREAD_MODEL questions References: <3A666455.54E28B8D@inprise.com> <3A666E6F.D58F546@floorboard.com> <3A6748F1.1D1F8A16@inprise.com> <3A67559E.E4502A26@cisco.com> <3A675A1C.3FDADD04@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: SaXd97fWd9F/7e9a > Hi Paul, > > comments inline.... > > Paul Kyzivat wrote: > > > comments inline below. > > > > Paul > > > > Andy Cutright wrote: > > > > > > i'm aware of this context, but i'd prefer that we leave the burden on the > > > application developer to make sure they call the function from the > > > appropriate thread, rather than stating 'for maximum portability an > > > application should..'. > > > > I believe this would be a very unfriendly thing to do, and would > > break lots of user code. > > > > My interpretation is that you can call run from whatever thread(s) > > you like. The orb is then free to decide which (if any) of them is > > the "main thread" and use it to do work. For any others, the orb is > > supposed to block the thread until shutdown. > > > > Of course, this still leaves a portability problem. If, in a particular > > implementation, there is a distinguished "main thread", and the user > > never calls run from that thread, the application may not work. > > I don't see any good solution to that. > > I agree. This would be application error. However, the converse is where things get > a little interesting. > What happens if the application calls run/perform work from more than one thread? > More specifically what thread does all POAs with the MAIN_THREAD_MODEL execute > their requests in? > > > > > > second, what happens if an application calls both run & perform_work? > > > > > and what happens if the application calls run from multiple threads? it > > > > > isn't really clear what the difference in request handling with regard > > > > > to the thread used is between run() & perform_work(). > > > > > > > > The result is implementation specific. In an environment where there is > > > > a distinguished "main thread", this is almost certainly an error. The > > > > intent of MAIN_THREAD_MODEL is only one thread to call run() or > > > > perform_work(), and that thread is the one to service POAS with > > > > MAIN_THREAD_MODEL. Other POAs with other threading models can coexist, > > > > and may or may not use the main thread as well. > > > > > > i agree that the end result of calling both run() & perform_work() should be > > > implementation specific, and i'd like to see language added to the spec to > > > make that point. > > > > I don't see why this should be any more implementation specific than > > doing either of these alone in a single thread is. > > > > If there is a distinguished main thread, then at most one of these can > > be it. > > The behavior for each is defined in isolation, and they don't ever > > conflict. > > With POAs that have MAIN_THREAD_MODEL, it would be necessary to locate that > "distinguished" main thread, right? > > > If there is no distinguished main thread, then the orb is free to choose > > one or the other (or neither) as the main thread. Again, once this is > > done > > the behavior is well defined. > > Again how does the ORB know that there is or isn't a "distinguished" main thread > (in the context of multiple threads calling run). > > > Bottom line - no new issues are introduced by actions in a second > > thread. > > > > > > > > > > > > > > > > > > right now the spec seems to imply through the use of the message loop > > > > > example in section 4.2.3.2 that perform_work is really intended to be > > > > > used to handle situations where a single thread must be used for _all_ > > > > > application activity. now add to that the note on pg 11-12 about using > > > > > the main thread model: > > > > > "Note - Not all environments have such a special requirement. If > > > > > not, while requests will be processessed sequentially, they may not all > > > > > be processed on the same thread." > > > > > > > > > > my interpretation is that ORB::run would be used in cases where you > > > > > simply want the POAs to be accessed sequentially, but the application > > > > > doesn't care about which thread the implementation uses, but you would > > > > > need to call perform_work to specifically hand the application defined > > > > > main thread to process requests. > > > > > > > > > > my suggestion (finally ;^) is that we should state perform_work should > > > > > be called, on whichever thread the application likes, if it wants to > > > > > hand a specific thread to the ORB to do work. otherwise, calling > > > > > ORB::run from any thread simply means the implementation is free to > > > > > handle requests for servants associated with main thread model POAs on > > > > > whatever thread the implementation may choose (including a new one), in > > > > > keeping > > > > > with the requirement that the requests be processed on each POA's > > > > > servants sequentially.. > > > > > > > > I'll have to disagree. What you describe is what SINGLE_THREAD_MODEL > > > > does. > > > > > > the single thread model doesn't make any guarantees about request processing > > > across multiple POAs. also, the note that i've mentioned specifically says > > > that some usages of the main thread model may result in multiple threads > > > being used to handle request on any given set of main thread model POAs. so > > > the distinction between the main thread model and the single thread model > > > isn't clear at that point. why have a main thread model, and then state in > > > some environments (which itself isn't specified) that the implementation may > > > use different threads to handle requests? the spec was changed from 2.3 to > > > 2.4 such that some of the lanuage that was used in 2.3 to describe the single > > > thread model is used in 2.4 to describe the main thread model. i think we > > > should push further to state the main thread model guarantees in all cases > > > that if the application calls run() or perform_work() that thread of > > > execution will be used to process requests. we can do away with my earlier > > > proposal to allow ORB::run() to mean that the implementation is free to > > > handle requests for main thread model with any thread in this case. > > > > My take is that run, or perform_work, is there simply to *offer* a > > thread to the > > orb. Then the orb can choose to use it or not. In and of itself this > > should not > > imply anything about synchrony of request processing or what thread > > anything runs on. > > I am afraid I have to disagree. I agree that in the absence of the > MAIN_THREAD_MODEL, what you say is correct, but in the case of the > MAIN_THREAD_MODEL it is necessary to determine what happens. The ORB has to choose > in this case. Not choosing it will totally break portability. Let's take a > scenario. > > I have a POA with MAIN_THREAD_MODEL and I call ORB.run on only one thread. If ORBs > have the freedom to not use it, then how am I guaranteed the MAIN_THREAD_MODEL > behavior expected. > > Second scenario: > > I have two POA with MAIN_THREAD_MODEL and I call ORB.run in multiple threads. Is > the ORB free to use any thread to dispatch requests as long as they are serialized > across all the MAIN_THREAD_MODEL poas? > > Vijay Sender: jbiggar@corvette.floorboard.com Message-ID: <3A6765FF.E23C019A@floorboard.com> Date: Thu, 18 Jan 2001 13:54:07 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Vijaykumar Natarajan CC: Paul Kyzivat , orb_revision@omg.org Subject: Re: MAIN_THREAD_MODEL questions References: <3A666455.54E28B8D@inprise.com> <3A666E6F.D58F546@floorboard.com> <3A6748F1.1D1F8A16@inprise.com> <3A67559E.E4502A26@cisco.com> <3A675A1C.3FDADD04@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: m!'e94KM!!%IT!!`?D!! Vijaykumar Natarajan wrote: > I agree. This would be application error. However, the converse is where > things get a little interesting. > What happens if the application calls run/perform work from more than one > thread? > More specifically what thread does all POAs with the MAIN_THREAD_MODEL execute > their requests in? We chose to leave this as implementation specific. If there is a distinguished "main thread", then the ORB must know how to identify it and use it properly. > With POAs that have MAIN_THREAD_MODEL, it would be necessary to locate that > "distinguished" main thread, right? Right. In some cases, there may be OS support that the ORB implementation can use to identify the "main thread". Otherwise, the ORB probably just picks the first thread to call run() or perform_work(). > > If there is no distinguished main thread, then the orb is free to choose > > one or the other (or neither) as the main thread. Again, once this is > > done > > the behavior is well defined. > > Again how does the ORB know that there is or isn't a "distinguished" main > thread (in the context of multiple threads calling run). The developer of the ORB has to figure out whether the environment requires a distinguished "main thread" or not and code the ORB to do the right thing. > I am afraid I have to disagree. I agree that in the absence of the > MAIN_THREAD_MODEL, what you say is correct, but in the case of the > MAIN_THREAD_MODEL it is necessary to determine what happens. The ORB > has to > choose in this case. Not choosing it will totally break > portability. Let's > take a scenario. > > I have a POA with MAIN_THREAD_MODEL and I call ORB.run on only one > thread. If > ORBs have the freedom to not use it, then how am I guaranteed the > MAIN_THREAD_MODEL behavior expected. I agree that the ORB should use the thread that called run(). > Second scenario: > > I have two POA with MAIN_THREAD_MODEL and I call ORB.run in multiple > threads. > Is the ORB free to use any thread to dispatch requests as long as > they are > serialized across all the MAIN_THREAD_MODEL poas? I think so. It could also just pick one of the two threads and run everything on that thread. The bottom line is that we are trying to walk a fine line between improving portability and the ability to integrate code with special thread requirements into a CORBA application without trying to be so prescriptive that we get in the way of valid ORB implementation and application choices. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 18 Jan 2001 17:06:26 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kukura Cc: Vijaykumar Natarajan , Paul Kyzivat , orb_revision@omg.org Subject: Re: MAIN_THREAD_MODEL questions References: <3A666455.54E28B8D@inprise.com> <3A666E6F.D58F546@floorboard.com> <3A6748F1.1D1F8A16@inprise.com> <3A67559E.E4502A26@cisco.com> <3A675A1C.3FDADD04@inprise.com> <3A676291.6CE0DF94@iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: IO*e9R>J!!^agd9\9B!! Bob Kukura wrote: > > I think we need to attempt to specify the distinguished main thread. > Unfortunately, this is going to have to be language and possibly OS > dependent. For C++ and C on common platforms, a reasonable definition > might be the thread in which the program's main() function and/or its > static constructors are called. This definition seems to address the > requirement of being compatable with any non-thread-aware (i.e. where > errno is not thread-specific) code in cases I know of. That was one of the original motivating reasons for adding the MAIN_THREAD_MODEL, so it would make sense to make that explicit. > For languages or > language environments which have no reasonable way to distinguish a > main > thread, nor a need to distinguish one, it could be defined for our > purposes as the thread in which ORB::run(), ORB::work_pending(), or > ORB::perform_work() is first called for that ORB instance. This seems very reasonable to me. Wouldn't stating this as the language independant requirement together with statement of an additional contraint for special platforms like C and C++, stated in the language mapping chapter with a statement like:ORB::run(), ORB::work_pending() or ORB::perform_work must be called in the thread in which the program's main() function and/or its static constructors are called, take care of it all? Jishnu. Date: Thu, 18 Jan 2001 14:07:38 -0800 From: "Andy Cutright" X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: orb_revision@omg.org Subject: Re: MAIN_THREAD_MODEL questions References: <3A666455.54E28B8D@inprise.com> <3A666E6F.D58F546@floorboard.com> <3A6748F1.1D1F8A16@inprise.com> <3A67559E.E4502A26@cisco.com> <3A675A1C.3FDADD04@inprise.com> <3A676291.6CE0DF94@iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: `M#!!6)K!!bCc!!cmh!! hi all, Bob Kukura wrote: > I think we need to attempt to specify the distinguished main thread. > Unfortunately, this is going to have to be language and possibly OS > dependent. For C++ and C on common platforms, a reasonable > definition > might be the thread in which the program's main() function and/or > its > static constructors are called. This definition seems to address the > requirement of being compatable with any non-thread-aware > (i.e. where > errno is not thread-specific) code in cases I know of. For languages > or > language environments which have no reasonable way to distinguish a > main > thread, nor a need to distinguish one, it could be defined for our > purposes as the thread in which ORB::run(), ORB::work_pending(), or > ORB::perform_work() is first called for that ORB instance. > if we just leave it up to the application to make sure it calls ORB::run(), etc., from the appropriate thread, that would solve the problems of backward compatibility with the current spec, lack of clarity in the specification, and be completely platform/ language neutral. in the application cases/ example that pop to mind, the application always knows which thread is _the_ thread. we just need to clarify that the application is responsible for making that determination. Date: Thu, 18 Jan 2001 14:39:27 -0800 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar CC: Vijaykumar Natarajan , Paul Kyzivat , orb_revision@omg.org Subject: Re: MAIN_THREAD_MODEL questions References: <3A666455.54E28B8D@inprise.com> <3A666E6F.D58F546@floorboard.com> <3A6748F1.1D1F8A16@inprise.com> <3A67559E.E4502A26@cisco.com> <3A675A1C.3FDADD04@inprise.com> <3A6765FF.E23C019A@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Slgd94[0e9QhI!!XW"e9 Hi Jon, Jonathan Biggar wrote: > Vijaykumar Natarajan wrote: > > I agree. This would be application error. However, the converse is where > > things get a little interesting. > > What happens if the application calls run/perform work from more than one > > thread? > > More specifically what thread does all POAs with the MAIN_THREAD_MODEL execute > > their requests in? > > We chose to leave this as implementation specific. If there is a > distinguished "main thread", then the ORB must know how to identify it > and use it properly. > > > With POAs that have MAIN_THREAD_MODEL, it would be necessary to locate that > > "distinguished" main thread, right? > > Right. In some cases, there may be OS support that the ORB > implementation can use to identify the "main thread". Otherwise, the > ORB probably just picks the first thread to call run() or > perform_work(). > > > > If there is no distinguished main thread, then the orb is free to choose > > > one or the other (or neither) as the main thread. Again, once this is > > > done > > > the behavior is well defined. > > > > Again how does the ORB know that there is or isn't a "distinguished" main > > thread (in the context of multiple threads calling run). > > The developer of the ORB has to figure out whether the environment > requires a distinguished "main thread" or not and code the ORB to do the > right thing. I don't think the ORB should have the responsibility to figure this out. In fact, the "environment" may be very specific to the application and may vary by application (I.e in a given OS/Lanugage/Platform, different apps may have different "main" threads. > > > > I am afraid I have to disagree. I agree that in the absence of the > > MAIN_THREAD_MODEL, what you say is correct, but in the case of the > > MAIN_THREAD_MODEL it is necessary to determine what happens. The >ORB has to > > choose in this case. Not choosing it will totally break >portability. Let's > > take a scenario. > > > > I have a POA with MAIN_THREAD_MODEL and I call ORB.run on only one >thread. If > > ORBs have the freedom to not use it, then how am I guaranteed the > > MAIN_THREAD_MODEL behavior expected. > > I agree that the ORB should use the thread that called run(). > > > Second scenario: > > > > I have two POA with MAIN_THREAD_MODEL and I call ORB.run in >multiple threads. > > Is the ORB free to use any thread to dispatch requests as long as >they are > > serialized across all the MAIN_THREAD_MODEL poas? > > I think so. It could also just pick one of the two threads and run > everything on that thread. > > The bottom line is that we are trying to walk a fine line between > improving portability and the ability to integrate code with special > thread requirements into a CORBA application without trying to be so > prescriptive that we get in the way of valid ORB implementation and > application choices. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org I am in favor of the proposal to make it clear that the first thread that calls ORB run would be treated as the distinguished main thread and all MAIN_THREAD_MODEL POAs will have requests serialized on that thread. Thanks, Vijay Date: Thu, 18 Jan 2001 17:49:44 -0500 From: Paul Kyzivat X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: orb_revision@omg.org Subject: Re: MAIN_THREAD_MODEL questions References: <3A666455.54E28B8D@inprise.com> <3A666E6F.D58F546@floorboard.com> <3A6748F1.1D1F8A16@inprise.com> <3A67559E.E4502A26@cisco.com> <3A675A1C.3FDADD04@inprise.com> <3A676291.6CE0DF94@iona.com> <3A67692A.8CC257C4@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: >4Rd9-M0!!cf@e9!G/!! Andy Cutright wrote: > > if we just leave it up to the application to make sure it calls ORB::run(), etc., from > the appropriate thread, that would solve the problems of backward compatibility with the > current spec, lack of clarity in the specification, and be completely platform/ language > neutral. in the application cases/ example that pop to mind, the application always knows > which thread is _the_ thread. we just need to clarify that the application is responsible > for making that determination. It is a *feature* of orb.run that you can call it from multiple threads, with the effect that they block until the orb shuts down. What you suggest would, I think, make it illegal to call orb.run from multiple threads. Date: Thu, 18 Jan 2001 14:56:51 -0800 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijaykumar Natarajan CC: Jonathan Biggar , Paul Kyzivat , orb_revision@omg.org Subject: Re: MAIN_THREAD_MODEL questions References: <3A666455.54E28B8D@inprise.com> <3A666E6F.D58F546@floorboard.com> <3A6748F1.1D1F8A16@inprise.com> <3A67559E.E4502A26@cisco.com> <3A675A1C.3FDADD04@inprise.com> <3A6765FF.E23C019A@floorboard.com> <3A67709F.53865BC1@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: /@fd9(&Zd9aA*!!H>n!! Vijaykumar Natarajan wrote: > I am in favor of the proposal to make it clear that the first thread that calls ORB > run would be treated as the distinguished main thread and all MAIN_THREAD_MODEL POAs > will have requests serialized on that thread. > > Thanks, > Vijay Add to that perform_work. I don't think work_pending needs to be added as it is not providing a thread for performing work. Also, if the user calls perform_work from different threads at different times, then I don't think we should prevent that. When multiple threads call perform_work simultaneously the first thread gets picked. Vijay Date: Thu, 18 Jan 2001 18:13:59 -0500 From: Paul Kyzivat X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: orb_revision@omg.org Subject: Re: MAIN_THREAD_MODEL questions References: <3A666455.54E28B8D@inprise.com> <3A666E6F.D58F546@floorboard.com> <3A6748F1.1D1F8A16@inprise.com> <3A67559E.E4502A26@cisco.com> <3A675A1C.3FDADD04@inprise.com> <3A6765FF.E23C019A@floorboard.com> <3A67709F.53865BC1@inprise.com> <3A6774B3.6BF5816C@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: o[K!!JkQ!!lH;!!:dl!! Vijaykumar Natarajan wrote: > > Add to that perform_work. I don't think work_pending needs to be added as it is not > providing a thread for performing work. Also, if the user calls perform_work from > different threads at different times, then I don't think we should prevent that. When > multiple threads call perform_work simultaneously the first thread gets picked. If multiple threads call simultaneously, which one is first? :-) All you are saying is that the orb gets to choose. Paul Date: Thu, 18 Jan 2001 15:36:48 -0800 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: orb_revision@omg.org Subject: Re: MAIN_THREAD_MODEL questions References: <3A666455.54E28B8D@inprise.com> <3A666E6F.D58F546@floorboard.com> <3A6748F1.1D1F8A16@inprise.com> <3A67559E.E4502A26@cisco.com> <3A675A1C.3FDADD04@inprise.com> <3A6765FF.E23C019A@floorboard.com> <3A67709F.53865BC1@inprise.com> <3A6774B3.6BF5816C@inprise.com> <3A6778B7.C1B32E6C@cisco.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: %?Me9RdA!!BB?e91Z Vijaykumar Natarajan wrote: > > > > Add to that perform_work. I don't think work_pending needs to be added as it is not > > providing a thread for performing work. Also, if the user calls perform_work from > > different threads at different times, then I don't think we should prevent that. When > > multiple threads call perform_work simultaneously the first thread gets picked. > > If multiple threads call simultaneously, which one is first? :-) > > All you are saying is that the orb gets to choose. > > Paul Date: Thu, 18 Jan 2001 21:49:55 -0500 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijaykumar Natarajan CC: Paul Kyzivat , orb_revision@omg.org Subject: Re: MAIN_THREAD_MODEL questions References: <3A666455.54E28B8D@inprise.com> <3A666E6F.D58F546@floorboard.com> <3A6748F1.1D1F8A16@inprise.com> <3A67559E.E4502A26@cisco.com> <3A675A1C.3FDADD04@inprise.com> <3A6765FF.E23C019A@floorboard.com> <3A67709F.53865BC1@inprise.com> <3A6774B3.6BF5816C@inprise.com> <3A6778B7.C1B32E6C@cisco.com> <3A677E10.19AA5065@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: bYn!!=cL!!>l^d9nRh!! I'm not happy with specifying that the first thread to call ORB::run() or ORB::perform_work() is from then on considered the main thread, no matter what. Some of the most common software environments for ORBs, C++ on Unix-like OSes and on Win32, have a distinguished main thread that is readily identified by ORB code. A valid interpretation of the original POA specification was that SINGLE_THREAD_MODEL POAs all dispatched invocations in this distinguished main thread. I believe this was the intent during the RFP process, as I recall Sun's representative arguing that non-thread-aware library code for SunOS had to be run in this distinguished thread or else its errno wouldn't work, but I do concede that the wording up through CORBA 2.3 was ambiguous, and this wasn't the only valid interpretation. But we did implement the Orbix 2000 C++ POA according to this interpretation. It does identify this distinguished main thread on all operating systems it currently supports. Its ORB::run() and ORB::perform_work() behave according to this interpretation, and it only dispatches SINGLE_THREAD_MODEL POA invocations in this distinguished main thread. We have no way of predicting to what extend our customers' applications depend on this implementation choice. It is entirely possible that some of our customers are calling ORB::run() in a thread other than the distinguished main thread prior to calling it in the main thread, and are depending on the main thread being used for SINGLE_THREAD_MODEL POAs. When the issue regarding this ambiguity came along, we were willing to go along with a resolution that allowed us to maintain our originally implemented behaviour for our customers' applications by simply requiring them to replace SINGLE_THREAD_MODEL with MAIN_THREAD_MODEL in their code when upgrading to a CORBA 2.4 compliant version of Orbix 2000. But we are not able to support a further resolution that would make Orbix 2000's identification and use of the distinguished main thread non-compliant for MAIN_THREAD_MODEL POAs. -Bob Vijaykumar Natarajan wrote: > > OK I see what you mean. The selection of who is first is arbitrary. But, once selected, the > selection sticks, until it is unset (this happens when no orb.run is called and all > perform_work() calls return). > > Vijay > Paul Kyzivat wrote: > > > Vijaykumar Natarajan wrote: > > > > > > Add to that perform_work. I don't think work_pending needs to be added as it is not > > > providing a thread for performing work. Also, if the user calls perform_work from > > > different threads at different times, then I don't think we should prevent that. When > > > multiple threads call perform_work simultaneously the first thread gets picked. > > > > If multiple threads call simultaneously, which one is first? :-) > > > > All you are saying is that the orb gets to choose. > > > > Paul Date: Fri, 19 Jan 2001 09:12:36 -0500 From: Paul Kyzivat X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: orb_revision@omg.org Subject: Re: MAIN_THREAD_MODEL questions References: <3A666455.54E28B8D@inprise.com> <3A666E6F.D58F546@floorboard.com> <3A6748F1.1D1F8A16@inprise.com> <3A67559E.E4502A26@cisco.com> <3A675A1C.3FDADD04@inprise.com> <3A6765FF.E23C019A@floorboard.com> <3A67709F.53865BC1@inprise.com> <3A6774B3.6BF5816C@inprise.com> <3A6778B7.C1B32E6C@cisco.com> <3A677E10.19AA5065@inprise.com> <3A67AB53.6CB2F35D@iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: \K,e9:^)e9]gW!!~\R!! I generally agree with Bob on this. In particular, I may call orb.run on several threads because I need to park them until the orb shuts down. One of these may be the "main thread" in the sense that Bob means it. But without writing a bunch of synchronization code I can't guarantee that run is called first on that thread. Paul Bob Kukura wrote: > > I'm not happy with specifying that the first thread to call ORB::run() > or ORB::perform_work() is from then on considered the main thread, no > matter what. Some of the most common software environments for ORBs, C++ > on Unix-like OSes and on Win32, have a distinguished main thread that is > readily identified by ORB code. A valid interpretation of the original > POA specification was that SINGLE_THREAD_MODEL POAs all dispatched > invocations in this distinguished main thread. I believe this was the > intent during the RFP process, as I recall Sun's representative arguing > that non-thread-aware library code for SunOS had to be run in this > distinguished thread or else its errno wouldn't work, but I do concede > that the wording up through CORBA 2.3 was ambiguous, and this wasn't the > only valid interpretation. > > But we did implement the Orbix 2000 C++ POA according to this > interpretation. It does identify this distinguished main thread on all > operating systems it currently supports. Its ORB::run() and > ORB::perform_work() behave according to this interpretation, and it only > dispatches SINGLE_THREAD_MODEL POA invocations in this distinguished > main thread. We have no way of predicting to what extend our customers' > applications depend on this implementation choice. It is entirely > possible that some of our customers are calling ORB::run() in a thread > other than the distinguished main thread prior to calling it in the main > thread, and are depending on the main thread being used for > SINGLE_THREAD_MODEL POAs. > > When the issue regarding this ambiguity came along, we were willing to > go along with a resolution that allowed us to maintain our originally > implemented behaviour for our customers' applications by simply > requiring them to replace SINGLE_THREAD_MODEL with MAIN_THREAD_MODEL in > their code when upgrading to a CORBA 2.4 compliant version of Orbix > 2000. But we are not able to support a further resolution that would > make Orbix 2000's identification and use of the distinguished main > thread non-compliant for MAIN_THREAD_MODEL POAs. > > -Bob > > Vijaykumar Natarajan wrote: > > > > OK I see what you mean. The selection of who is first is arbitrary. But, once selected, the > > selection sticks, until it is unset (this happens when no orb.run is called and all > > perform_work() calls return). > > > > Vijay > > Paul Kyzivat wrote: > > > > > Vijaykumar Natarajan wrote: > > > > > > > > Add to that perform_work. I don't think work_pending needs to be added as it is not > > > > providing a thread for performing work. Also, if the user calls perform_work from > > > > different threads at different times, then I don't think we should prevent that. When > > > > multiple threads call perform_work simultaneously the first thread gets picked. > > > > > > If multiple threads call simultaneously, which one is first? :-) > > > > > > All you are saying is that the orb gets to choose. > > > > > > Paul Date: Fri, 19 Jan 2001 11:54:41 -0800 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kukura CC: Vijaykumar Natarajan , Paul Kyzivat , orb_revision@omg.org Subject: Re: MAIN_THREAD_MODEL questions References: <3A666455.54E28B8D@inprise.com> <3A666E6F.D58F546@floorboard.com> <3A6748F1.1D1F8A16@inprise.com> <3A67559E.E4502A26@cisco.com> <3A675A1C.3FDADD04@inprise.com> <3A6765FF.E23C019A@floorboard.com> <3A67709F.53865BC1@inprise.com> <3A6774B3.6BF5816C@inprise.com> <3A6778B7.C1B32E6C@cisco.com> <3A677E10.19AA5065@inprise.com> <3A67AB53.6CB2F35D@iona.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: +ILe9'~X!!**Y!!AVI!! Hi all, > Some of the most common software environments for ORBs, C++ > on Unix-like OSes and on Win32, have a distinguished main thread > that is > readily identified by ORB code. I know of no guaranteed way to determine the "distinguished" main thread such that it is the same thread that is selected by any ORB vendor. This is a portability problem. Even if the ORB is able to identify this purported main thread, what guarantee does the ORB have that the application may not exit this thread. This is possible both in posix and Java. You said earlier: "For languages or language environments which have no reasonable way to distinguish a main thread, nor a need to distinguish one, it could be defined for our purposes as the thread in which ORB::run(), ORB::work_pending(), or ORB::perform_work() is first called for that ORB instance. " And now you say: "I'm not happy with specifying that the first thread to call ORB::run() or ORB::perform_work() is from then on considered the main thread, no matter what." In the former you indicate that in some environments it would be OK to pick the first thread as the main thread, but in the latter you are opposed to that. Also, Are we saying that the spec should specify for each language and OS environment how the distinguished main thread is picked? I agree with Paul's issue of having to use significant synchronization to ensure that the main thread calls ORB run first. However, I think that needs to be solved by other means than doing this platform/language specific auto detection of the main thread. Also, as Andy pointed out earlier, the main thread model description has the following note: Note - Not all environments have such a special requirement. If not, while requests will be processed sequentially they might not all be processed by the same thread. How does the ORB determine that it is running in such an environment? I believe in order to have portable code on the server side, we need to nail down how an ORB determines what this "distinguished" main thread, and not leave it to be implementation dependent and/or platform specific. We absolutely need to clarify this. thanks, Vijay Bob Kukura wrote: > I'm not happy with specifying that the first thread to call ORB::run() > or ORB::perform_work() is from then on considered the main thread, no > matter what. Some of the most common software environments for ORBs, C++ > on Unix-like OSes and on Win32, have a distinguished main thread that is > readily identified by ORB code. A valid interpretation of the original > POA specification was that SINGLE_THREAD_MODEL POAs all dispatched > invocations in this distinguished main thread. I believe this was the > intent during the RFP process, as I recall Sun's representative arguing > that non-thread-aware library code for SunOS had to be run in this > distinguished thread or else its errno wouldn't work, but I do concede > that the wording up through CORBA 2.3 was ambiguous, and this wasn't the > only valid interpretation. > > But we did implement the Orbix 2000 C++ POA according to this > interpretation. It does identify this distinguished main thread on all > operating systems it currently supports. Its ORB::run() and > ORB::perform_work() behave according to this interpretation, and it only > dispatches SINGLE_THREAD_MODEL POA invocations in this distinguished > main thread. We have no way of predicting to what extend our customers' > applications depend on this implementation choice. It is entirely > possible that some of our customers are calling ORB::run() in a thread > other than the distinguished main thread prior to calling it in the main > thread, and are depending on the main thread being used for > SINGLE_THREAD_MODEL POAs. > > When the issue regarding this ambiguity came along, we were willing to > go along with a resolution that allowed us to maintain our originally > implemented behaviour for our customers' applications by simply > requiring them to replace SINGLE_THREAD_MODEL with MAIN_THREAD_MODEL in > their code when upgrading to a CORBA 2.4 compliant version of Orbix > 2000. But we are not able to support a further resolution that would > make Orbix 2000's identification and use of the distinguished main > thread non-compliant for MAIN_THREAD_MODEL POAs. > > -Bob > > Vijaykumar Natarajan wrote: > > > > OK I see what you mean. The selection of who is first is arbitrary. But, once selected, the > > selection sticks, until it is unset (this happens when no orb.run is called and all > > perform_work() calls return). > > > > Vijay > > Paul Kyzivat wrote: > > > > > Vijaykumar Natarajan wrote: > > > > > > > > Add to that perform_work. I don't think work_pending needs to be added as it is not > > > > providing a thread for performing work. Also, if the user calls perform_work from > > > > different threads at different times, then I don't think we should prevent that. When > > > > multiple threads call perform_work simultaneously the first thread gets picked. > > > > > > If multiple threads call simultaneously, which one is first? :-) > > > > > > All you are saying is that the orb gets to choose. > > > > > > Paul Date: Fri, 19 Jan 2001 16:57:05 -0500 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijaykumar Natarajan CC: Paul Kyzivat , orb_revision@omg.org Subject: Re: MAIN_THREAD_MODEL questions References: <3A666455.54E28B8D@inprise.com> <3A666E6F.D58F546@floorboard.com> <3A6748F1.1D1F8A16@inprise.com> <3A67559E.E4502A26@cisco.com> <3A675A1C.3FDADD04@inprise.com> <3A6765FF.E23C019A@floorboard.com> <3A67709F.53865BC1@inprise.com> <3A6774B3.6BF5816C@inprise.com> <3A6778B7.C1B32E6C@cisco.com> <3A677E10.19AA5065@inprise.com> <3A67AB53.6CB2F35D@iona.com> <3A689B81.BB069E94@inprise.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: ad:e9[U!"!Y9\d9/$Ie9 Vijaykumar Natarajan wrote: > > Hi all, > > > Some of the most common software environments for ORBs, C++ > > on Unix-like OSes and on Win32, have a distinguished main thread that is > > readily identified by ORB code. > > I know of no guaranteed way to determine the "distinguished" main thread such that it is the same > thread that is selected by any ORB vendor. This is a portability problem. On Posix systems, Orbix 2000 determines the main thread in C++ by calling pthread_self() during static construction and remembering its ID. As long as the ORB is linked, directly or indirectly, with the application, this identifies the thread that the application's main() is called in for all the Unix-like OSes with Posix thread implementations that we know of. If the ORB shared libraries are runtime dynamically loaded into the application from a thread other than the one in which main() was called, then this technique might not identify the main thread correctly, but I don't think this is a problem in practice. If an ORB is being dynamically loaded, it has no business expecting to control the main thread, and therefore should not use MAIN_THREAD_MODEL POAs. I can see how these sorts of implementation techniques, although useful from a product perspective on a given set of platforms, may not be considered an adequate basis for the CORBA specification. I want to be as flexible as possible in finding a solution here, but I also need to make sure there is a reasonable way forward for existing applications that depend on IONA's interpretation of the original POA specification. If we are to keep the notion of a distinguished main thread (note that I propose an alternative below), would it be reasonable to specify something like the following? The MAIN_THREAD_MODEL POA policy, and the associated special functionality of ORB::run() and ORB::perform_work() when invoked in the main thread, are intended to support language environments where certain code may need to be executed in a distinguished main thread. How an ORB identifies the distinguished main thread is language mapping dependent and also potentially platform and vendor dependent. The following rules apply: * In C and C++ environments, the thread in which the application's main() function is called is considered the main thread. But an ORB vendor may document circumstances (for example runtime dynamic loading of the ORB, or certain realtime environments) in which this main thread cannot be distinguished, and then document how a main thread is selected in those circumstances. * In environments, such as Java, where there is no need to treat a distinguished main thread specially, the first thread in which ORB::run() or ORB::perform_work() is called is considered the main thread for that ORB instance. * Language mappings must specify which of the above two rules apply. I think this may be the best we can do if we want to preserve the originally intended semantics for SINGLE_THREAD_MODEL (renamed in 2.4 to MAIN_THREAD_MODEL), ORB::run(), and ORB::perform_work(). > > Even if the ORB is able to identify this purported main thread, what > guarantee does the ORB have > that the application may not exit this thread. This is possible both > in posix and Java. If the ORB is using MAIN_THREAD_MODEL POAs and therefore depending on invocations being dispatched in the main thread, then exiting this main thread would be an application error. I don't think we need to address this in the specification. > > You said earlier: > "For languages or > language environments which have no reasonable way to distinguish a > main > thread, nor a need to distinguish one, it could be defined for our > purposes as the thread in which ORB::run(), ORB::work_pending(), or > ORB::perform_work() is first called for that ORB instance. > " > And now you say: > "I'm not happy with specifying that the first thread to call > ORB::run() > or ORB::perform_work() is from then on considered the main thread, > no > matter what." In the first case, I was admitting that a distiguished main thread cannot always be identified, and was suggesting a way to handle that situation. In the second case, I was arguing against using the that fallback technique in situations, such as C or C++ on common platforms, where it is possible and (arguably) useful to distinguish a main thread. > > In the former you indicate that in some environments it would be OK > to pick the first thread as > the main thread, but in the latter you are opposed to that. Also, > Are we saying that the spec > should specify for each language and OS environment how the > distinguished main thread is picked? It seems specifying this for each language is necessary. I don't think we should be specifying it for individual platforms, though. Unfortunately, the original motivation for this "main thread" functionality was very OS and language specific. It should probably have been specified in a different way, with the onus on the application to call some special function in the main thread rather than on the ORB to identify the main thread. > > I agree with Paul's issue of having to use significant > synchronization to ensure that the main > thread calls ORB run first. However, I think that needs to be solved > by other means than doing > this platform/language specific auto detection of the main thread. > > Also, as Andy pointed out earlier, the main thread model description > has the following note: > Note - Not all environments have such a special requirement. If not, > while requests will > be processed sequentially they might not all be processed by the > same thread. > > How does the ORB determine that it is running in such an > environment? As things stand, I guess this would have to be documented by the vendor, and would be a portability concern. I will admit that I missed the part about these requests not necessarily being processed in the same thread, and assumed these were always processed within some call to ORB::run() or ORB::perform_work(). I'm concerned that some applications might require a guarantee that MAIN_THREAD_MODEL invocations are not executed concurrently with code run between calls to ORB::perform_work(). > > I believe in order to have portable code on the server side, we need > to nail down how an ORB > determines what this "distinguished" main thread, and not leave it > to be implementation dependent > and/or platform specific. We absolutely need to clarify this. Why not make the distinction between waiting for the ORB to shutdown and giving the ORB a thread to use for MAIN_THREAD_MODEL invocations explicit? This would eliminate any need for the ORB to identify a distinguished main thread, and would therefore eliminate language and platform dependencies. One approach would be to respecify ORB::run() as simply waiting for the ORB to have completely shut down, and add a new ORB::run_main() operation that does the same thing but also processes MAIN_THREAD_MODEL invocations. Then we could specify that MAIN_THREAD_MODEL invocations are processed within calls to either ORB::run_main() or ORB::perform_work(), and that calling more than one of these functions concurrently results in BAD_INV_ORDER. It would be up to the application to call one of these from any appropriate distinguished thread where that is necessary. CORBA 2.4 applications that use MAIN_THREAD_MODEL with ORB::run() would then have to be modified to call ORB::run_main() instead in any one thread, but this doesn't seem any worse than having to switch from SINGLE_THREAD_MODEL to MAIN_THREAD_MODEL. -Bob > > thanks, > Vijay > > Bob Kukura wrote: > > > I'm not happy with specifying that the first thread to call > ORB::run() > > or ORB::perform_work() is from then on considered the main thread, > no > > matter what. Some of the most common software environments for > ORBs, C++ > > on Unix-like OSes and on Win32, have a distinguished main thread > that is > > readily identified by ORB code. A valid interpretation of the > original > > POA specification was that SINGLE_THREAD_MODEL POAs all dispatched > > invocations in this distinguished main thread. I believe this was > the > > intent during the RFP process, as I recall Sun's representative > arguing > > that non-thread-aware library code for SunOS had to be run in this > > distinguished thread or else its errno wouldn't work, but I do > concede > > that the wording up through CORBA 2.3 was ambiguous, and this > wasn't the > > only valid interpretation. > > > > But we did implement the Orbix 2000 C++ POA according to this > > interpretation. It does identify this distinguished main thread on > all > > operating systems it currently supports. Its ORB::run() and > > ORB::perform_work() behave according to this interpretation, and > it only > > dispatches SINGLE_THREAD_MODEL POA invocations in this > distinguished > > main thread. We have no way of predicting to what extend our > customers' > > applications depend on this implementation choice. It is entirely > > possible that some of our customers are calling ORB::run() in a > thread > > other than the distinguished main thread prior to calling it in > the main > > thread, and are depending on the main thread being used for > > SINGLE_THREAD_MODEL POAs. > > > > When the issue regarding this ambiguity came along, we were > willing to > > go along with a resolution that allowed us to maintain our > originally > > implemented behaviour for our customers' applications by simply > > requiring them to replace SINGLE_THREAD_MODEL with > MAIN_THREAD_MODEL in > > their code when upgrading to a CORBA 2.4 compliant version of > Orbix > > 2000. But we are not able to support a further resolution that > would > > make Orbix 2000's identification and use of the distinguished main > > thread non-compliant for MAIN_THREAD_MODEL POAs. > > > > -Bob > > > > Vijaykumar Natarajan wrote: > > > > > > OK I see what you mean. The selection of who is first is > arbitrary. But, once selected, the > > > selection sticks, until it is unset (this happens when no > orb.run is called and all > > > perform_work() calls return). > > > > > > Vijay > > > Paul Kyzivat wrote: > > > > > > > Vijaykumar Natarajan wrote: > > > > > > > > > > Add to that perform_work. I don't think work_pending needs > to be added as it is not > > > > > providing a thread for performing work. Also, if the user > calls perform_work from > > > > > different threads at different times, then I don't think we > should prevent that. When > > > > > multiple threads call perform_work simultaneously the first > thread gets picked. > > > > > > > > If multiple threads call simultaneously, which one is first? > :-) > > > > > > > > All you are saying is that the orb gets to choose. > > > > > > > > Paul Date: Fri, 19 Jan 2001 15:00:47 -0800 From: "Andy Cutright" X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: orb_revision@omg.org, kukura@iona.com, pkyzivat@cisco.com Subject: Re: MAIN_THREAD_MODEL questions References: <3A666455.54E28B8D@inprise.com> <3A666E6F.D58F546@floorboard.com> <3A6748F1.1D1F8A16@inprise.com> <3A67559E.E4502A26@cisco.com> <3A675A1C.3FDADD04@inprise.com> <3A6765FF.E23C019A@floorboard.com> <3A67709F.53865BC1@inprise.com> <3A6774B3.6BF5816C@inprise.com> <3A6778B7.C1B32E6C@cisco.com> <3A677E10.19AA5065@inprise.com> <3A67AB53.6CB2F35D@iona.com> <3A689B81.BB069E94@inprise.com> <3A68B831.BE7F8A9D@iona.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: b*Qe98&m!!;G@!! Vijaykumar Natarajan wrote: > > > > I know of no guaranteed way to determine the "distinguished" main thread such that it is the same > > thread that is selected by any ORB vendor. This is a portability problem. > > On Posix systems, Orbix 2000 determines the main thread in C++ by > calling pthread_self() during static construction and remembering its > ID. As long as the ORB is linked, directly or indirectly, with the > application, this identifies the thread that the application's main() is > called in for all the Unix-like OSes with Posix thread implementations > that we know of. If the ORB shared libraries are runtime dynamically > loaded into the application from a thread other than the one in which > main() was called, then this technique might not identify the main > thread correctly, but I don't think this is a problem in practice. If an > ORB is being dynamically loaded, it has no business expecting to control > the main thread, and therefore should not use MAIN_THREAD_MODEL POAs. 'in practice' is a dangerous generalization. maybe the application really intends to hand over some specific thread to the ORB, which isn't the main thread according to this algorithm. why are we preventing it? also, why does dynamic loading prohibit usage in this model? the ORB cannot detect this in any reliable way. also, it's not the ORB using the main thread model, it's the application, and the ORB cannot dictate the model. > > > I can see how these sorts of implementation techniques, although >useful > from a product perspective on a given set of platforms, may not be > considered an adequate basis for the CORBA specification. I want to >be > as flexible as possible in finding a solution here, but I also need >to > make sure there is a reasonable way forward for existing >applications > that depend on IONA's interpretation of the original POA >specification. > If we are to keep the notion of a distinguished main thread (note >that I > propose an alternative below), would it be reasonable to specify > something like the following? > > The MAIN_THREAD_MODEL POA policy, and the associated special > functionality of ORB::run() and ORB::perform_work() when invoked in >the > main thread, are intended to support language environments where >certain > code may need to be executed in a distinguished main thread. How an >ORB > identifies the distinguished main thread is language mapping >dependent > and also potentially platform and vendor dependent. The following >rules > apply: > > * In C and C++ environments, the thread in which the application's > main() function is called is considered the main thread. But an ORB > vendor may document circumstances (for example runtime dynamic >loading > of the ORB, or certain realtime environments) in which this main >thread > cannot be distinguished, and then document how a main thread is >selected > in those circumstances. > > > * In environments, such as Java, where there is no need to treat a > distinguished main thread specially, the first thread in which > ORB::run() or ORB::perform_work() is called is considered the main > thread for that ORB instance. this isn't good. a java application may be using JNI and it may want to interface with legacy code, requiring a distinguished thread. > > > * Language mappings must specify which of the above two rules >apply. > > I think this may be the best we can do if we want to preserve the > originally intended semantics for SINGLE_THREAD_MODEL (renamed in >2.4 to > MAIN_THREAD_MODEL), ORB::run(), and ORB::perform_work(). > > > > > Even if the ORB is able to identify this purported main thread, >what guarantee does the ORB have > > that the application may not exit this thread. This is possible >both in posix and Java. > > If the ORB is using MAIN_THREAD_MODEL POAs and therefore depending >on > invocations being dispatched in the main thread, then exiting this >main > thread would be an application error. I don't think we need to >address > this in the specification. > > > > > You said earlier: > > "For languages or > > language environments which have no reasonable way to distinguish >a main > > thread, nor a need to distinguish one, it could be defined for our > > purposes as the thread in which ORB::run(), ORB::work_pending(), >or > > ORB::perform_work() is first called for that ORB instance. > > " > > And now you say: > > "I'm not happy with specifying that the first thread to call >ORB::run() > > or ORB::perform_work() is from then on considered the main thread, >no > > matter what." > > In the first case, I was admitting that a distiguished main thread > cannot always be identified, and was suggesting a way to handle that > situation. In the second case, I was arguing against using the that > fallback technique in situations, such as C or C++ on common >platforms, > where it is possible and (arguably) useful to distinguish a main >thread. > > > > > In the former you indicate that in some environments it would be >OK to pick the first thread as > > the main thread, but in the latter you are opposed to that. Also, >Are we saying that the spec > > should specify for each language and OS environment how the >distinguished main thread is picked? > > It seems specifying this for each language is necessary. I don't >think > we should be specifying it for individual platforms, though. > Unfortunately, the original motivation for this "main thread" > functionality was very OS and language specific. It should probably >have > been specified in a different way, with the onus on the application >to > call some special function in the main thread rather than on the ORB >to > identify the main thread. That might be the best solution. > > > > > > I agree with Paul's issue of having to use significant >synchronization to ensure that the main > > thread calls ORB run first. However, I think that needs to be >solved by other means than doing > > this platform/language specific auto detection of the main thread. > > > > Also, as Andy pointed out earlier, the main thread model >description has the following note: > > Note - Not all environments have such a special requirement. If >not, while requests will > > be processed sequentially they might not all be processed by the >same thread. > > > > How does the ORB determine that it is running in such an >environment? > > As things stand, I guess this would have to be documented by the >vendor, > and would be a portability concern. > > I will admit that I missed the part about these requests not >necessarily > being processed in the same thread, and assumed these were always > processed within some call to ORB::run() or ORB::perform_work(). I'm > concerned that some applications might require a guarantee that > MAIN_THREAD_MODEL invocations are not executed concurrently with >code > run between calls to ORB::perform_work(). Agreed. I think this guarantee should be provided. > > > > > > I believe in order to have portable code on the server side, we >need to nail down how an ORB > > determines what this "distinguished" main thread, and not leave it >to be implementation dependent > > and/or platform specific. We absolutely need to clarify this. > > Why not make the distinction between waiting for the ORB to shutdown >and > giving the ORB a thread to use for MAIN_THREAD_MODEL invocations > explicit? This would eliminate any need for the ORB to identify a > distinguished main thread, and would therefore eliminate language >and > platform dependencies. One approach would be to respecify ORB::run() >as > simply waiting for the ORB to have completely shut down, and add a >new > ORB::run_main() operation that does the same thing but also >processes > MAIN_THREAD_MODEL invocations. Then we could specify that > MAIN_THREAD_MODEL invocations are processed within calls to either > ORB::run_main() or ORB::perform_work(), and that calling more than >one > of these functions concurrently results in BAD_INV_ORDER. It would >be up > to the application to call one of these from any appropriate > distinguished thread where that is necessary. CORBA 2.4 applications > that use MAIN_THREAD_MODEL with ORB::run() would then have to be > modified to call ORB::run_main() instead in any one thread, but this > doesn't seem any worse than having to switch from >SINGLE_THREAD_MODEL to > MAIN_THREAD_MODEL. we like this :^) cheers, andy@inprise.com soon to be borlander Date: Fri, 19 Jan 2001 15:46:16 -0800 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Andy Cutright CC: orb_revision@omg.org, kukura@iona.com, pkyzivat@cisco.com Subject: Re: MAIN_THREAD_MODEL questions References: <3A666455.54E28B8D@inprise.com> <3A666E6F.D58F546@floorboard.com> <3A6748F1.1D1F8A16@inprise.com> <3A67559E.E4502A26@cisco.com> <3A675A1C.3FDADD04@inprise.com> <3A6765FF.E23C019A@floorboard.com> <3A67709F.53865BC1@inprise.com> <3A6774B3.6BF5816C@inprise.com> <3A6778B7.C1B32E6C@cisco.com> <3A677E10.19AA5065@inprise.com> <3A67AB53.6CB2F35D@iona.com> <3A689B81.BB069E94@inprise.com> <3A68B831.BE7F8A9D@iona.com> <3A68C71F.476C024D@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: QFGe9]dIe9UV6e9;I`!! > > functionality was very OS and language specific. It should probably have > > been specified in a different way, with the onus on the application to > > call some special function in the main thread rather than on the ORB to > > identify the main thread. > > That might be the best solution. For some reaon I thought that was already how orb.run or orb.perform_work already worked. It was the application's responsibility to call one or the other of these with the main thread. H Date: Fri, 19 Jan 2001 16:01:09 -0800 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Harold Carr CC: Andy Cutright , orb_revision@omg.org, kukura@iona.com, pkyzivat@cisco.com Subject: Re: MAIN_THREAD_MODEL questions References: <3A666455.54E28B8D@inprise.com> <3A666E6F.D58F546@floorboard.com> <3A6748F1.1D1F8A16@inprise.com> <3A67559E.E4502A26@cisco.com> <3A675A1C.3FDADD04@inprise.com> <3A6765FF.E23C019A@floorboard.com> <3A67709F.53865BC1@inprise.com> <3A6774B3.6BF5816C@inprise.com> <3A6778B7.C1B32E6C@cisco.com> <3A677E10.19AA5065@inprise.com> <3A67AB53.6CB2F35D@iona.com> <3A689B81.BB069E94@inprise.com> <3A68B831.BE7F8A9D@iona.com> <3A68C71F.476C024D@inprise.com> <3A68D1C8.78C29356@sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: L,j!!F^gd9]9ad9K49!! Hi Harold, The issue was that when multiple threads called orb.run there was an ambiguity as to which of those would be the "distinguished" main thread. Vijay Harold Carr wrote: > > > functionality was very OS and language specific. It should probably have > > > been specified in a different way, with the onus on the application to > > > call some special function in the main thread rather than on the ORB to > > > identify the main thread. > > > > That might be the best solution. > > For some reaon I thought that was already how orb.run or > orb.perform_work already worked. It was the application's > responsibility to call one or the other of these with the main thread. > > H Date: Wed, 24 Jan 2001 18:11:43 -0800 From: "Andy Cutright" X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar CC: orb_revision@omg.org Subject: Re: MAIN_THREAD_MODEL questions References: <3A666455.54E28B8D@inprise.com> <3A666E6F.D58F546@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: I),e9!hZd9i5>e9'SKe9 hi jonathon & all, Jonathan Biggar wrote: > Andy Cutright wrote: > > > > hi all, > > > > > one more question: does it make sense to state that a callback type of > > architecture won't work when using this threading model? > > No, since it might actually work, depending on the application and the > programming environment. > there appears to be consensus about the behavior of a main thread model, with regard to which thread is doing the work as well as the policy's intended semantics. once again i ask, does it make sense to say that callbacks are explicitly disallowed? if only one thread can be doing the work, and it must be done sequentially, how can that thread be doing work in response to a request while it's issuing another request? i'm specifically concerned about this because of location transparency. it's certainly possible that a thread with a process can be made to behave that way. however, if the request goes out of process, how can it be that thread may do other work while a request is being processed? cheers, andy cutright borland Date: Thu, 25 Jan 2001 12:28:00 +1000 (EST) From: Michi Henning To: Andy Cutright cc: Jonathan Biggar , orb_revision@omg.org Subject: Re: MAIN_THREAD_MODEL questions In-Reply-To: <3A6F8B5F.FA56014B@inprise.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: kpNe9-FC!!?Ah!!A5L!! On Wed, 24 Jan 2001, Andy Cutright wrote: > there appears to be consensus about the behavior of a main thread model, with > regard to which thread is doing the work as well as the policy's intended > semantics. once again i ask, does it make sense to say that callbacks are > explicitly disallowed? if only one thread can be doing the work, and it must > be done sequentially, how can that thread be doing work in response to a > request while it's issuing another request? Have a look at the reactive model used in ORBacus. Basically, after sending the request, the calling thread doesn't go into a blocking read on the connection to the server. Instead, it calls select, so it can react to an incoming callback even while the reply to some other request is outstanding. Cheers, Michi. -- Michi Henning +61 7 3324 9633 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 8 Martha St +61 7 3324 9799 (fax) Camp Hill 4152 michi@ooc.com.au Brisbane, AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Wed, 24 Jan 2001 18:33:22 -0800 From: "Andy Cutright" X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Andy Cutright , Jonathan Biggar , orb_revision@omg.org Subject: Re: MAIN_THREAD_MODEL questions References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ^>Qe9cJ(e9@Lk!!MXK!! hi michi, yeah, this model can be implemented, clearly. we've done the same sort of thing. the issue is should this be allowed? one of the reasons for the main thread policy is that it can deal with unthread safe code without any significant intervention on the application's part. specifically, a developer shouldn't have to protect any data structures from reentrancy. most single threaded applications expect this sort of behavior, cheers, andy Michi Henning wrote: > On Wed, 24 Jan 2001, Andy Cutright wrote: > > > there appears to be consensus about the behavior of a main thread >model, with > > regard to which thread is doing the work as well as the policy's >intended > > semantics. once again i ask, does it make sense to say that >callbacks are > > explicitly disallowed? if only one thread can be doing the work, >and it must > > be done sequentially, how can that thread be doing work in >response to a > > request while it's issuing another request? > > Have a look at the reactive model used in ORBacus. Basically, after > sending the request, the calling thread doesn't go into a blocking >read > on the connection to the server. Instead, it calls select, so it can > react to an incoming callback even while the reply to some other >request > is outstanding. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3324 9633 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 8 Martha St +61 7 3324 9799 (fax) > Camp Hill 4152 michi@ooc.com.au > Brisbane, AUSTRALIA >http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 25 Jan 2001 12:37:27 +1000 (EST) From: Michi Henning To: Andy Cutright cc: Jonathan Biggar , orb_revision@omg.org Subject: Re: MAIN_THREAD_MODEL questions In-Reply-To: <3A6F9072.736EDA6C@inprise.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: )b@!!:O2!!']l!!SR%!! On Wed, 24 Jan 2001, Andy Cutright wrote: > yeah, this model can be implemented, clearly. we've done the same sort of thing. > the issue is should this be allowed? one of the reasons for the main thread policy > is that it can deal with unthread safe code without any significant intervention on > the application's part. specifically, a developer shouldn't have to protect any > data structures from reentrancy. most single threaded applications expect this sort > of behavior, I see your point but I'd be loath to disallow reactive dispatch, especially when considering that this is the only way to get nested callbacks to work in a single-threaded program. Basically, if I choose the reactive model, it's expect that I will make my operations reentrant. So, I think that reactive dispatch should definitely be allowed. Cheers, Michi. -- Michi Henning +61 7 3324 9633 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 8 Martha St +61 7 3324 9799 (fax) Camp Hill 4152 michi@ooc.com.au Brisbane, AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Wed, 23 Oct 2002 16:05:32 -0400 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: corba-rtf@omg.org Subject: Proposed resolution for Issue 4155 The following resolution will appear in the next vote unless there is significant technical objection to it together with a concrete idea on how to proceed out of the deadlock. Thanks, Jishnu. ___________________________________________________________________ Issue 4155: MAIN_THREAD_MODEL questions (orb_revision) Click http://cgi.omg.org/issues/issue4155.txt for this issue's archive. Source: Borland Software Corporation (Mr. Andy Cutright, acutright@borland.com ) Nature: Uncategorized Issue Severity: Summary: I have a few questions about the POA ThreadPolicy type MAIN_THREAD_MODEL. .... etc....... Resolution: The discussion in the archive suggests that it is not possible to arrive at a consensus on making any of these changes that do not break at least some deplyed systems and the gains from making the change don't appear to justify the making of the change. Close no change Revised Text: Actions taken: Close no change Date: Tue, 05 Nov 2002 15:46:37 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Juergen Boldt Subject: Transfer Issue 4155 to Firewall FTF The subject line says it all. Please transfer issue 4155 to Firewall FTF as per the vote just completing in CORBA Core RTF. Thanks, Jishnu