Legacy Issue Number: 4155
Source: Borland Software Corporation ( Andy Cutright)
i have a few questions about the POA ThreadPolicy type
first, the 2.4.1 spec (00-11-03), sec 220.127.116.11 , '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 18.104.22.168, 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 22.214.171.124 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
with the requirement that the requests be processed on each POA's
one more question: does it make sense to state that a callback type of
architecture won't work when using this threading model?
Reported: CORBA 2.4.1 — Wed, 17 Jan 2001 05:00 GMT
Disposition: Deferred — CORBA 3.4
This proposal was generated automatically by request of the Task Force Chair Adam Mitz.
Updated: Wed, 1 Feb 2023 21:59 GMT