ChangeLogTag:Sat Aug 8 21:28:33 1998 Carlos O'Ryan <coryan@cs.wustl.edu>

3 files changed, 89 insertions, 0 deletions

diff --git a/TAO/ChangeLog-98c b/TAO/ChangeLog-98c
index ff731df1cc5..fe6de266c9b 100644
--- a/TAO/ChangeLog-98c
+++ b/TAO/ChangeLog-98c
@@ -5,6 +5,13 @@ Sat Aug  8 21:28:33 1998  Carlos O'Ryan  <coryan@cs.wustl.edu>
 	* tao/Exception.cpp: 
 	  Removed superflous operator new and operator delete.
 
+	* docs/releasenotes/TODO.html: 
+	  More updates.
+
+	* docs/configurations.html: 
+	  Added a few hints on when to use ORB-per-thread and what the
+	  consequences are.
+
 Fri Aug  7 21:39:26 1998  Carlos O'Ryan  <coryan@cs.wustl.edu>
 
 	* docs/releasenotes/TODO.html: 
diff --git a/TAO/docs/configurations.html b/TAO/docs/configurations.html
index 61a0f82916c..1f2390e30aa 100644
--- a/TAO/docs/configurations.html
+++ b/TAO/docs/configurations.html
@@ -443,6 +443,66 @@ NAME="multiorb-tpool"></A> (Not yet implemented.)
 </UL>
 </blockquote>
 
+<HR>
+
+<H3 ALIGN=CENTER>Hints</H3>
+
+    <P>
+      Choosing the right configuration is hard and,
+      of course,
+      depends on your application.
+      In the following section we will attempt to describe some
+      motivations for features in TAO,
+      hopefully that can guide you through the choice of your
+      configuration options.
+    </P>
+
+    <UL>
+      <LI>
+	<P><B>ORB-per-thread</B>
+	  The main motivation behind this options
+	  is to minimize priority invertion,
+	  since threads share no ORB resources no locking is required
+	  and thus,
+	  priority is preserved in most cases (assuming proper support
+	  from the OS).
+	  If you are not too concerned about priority inversion try to
+	  use a global ORB,
+	  using ORB-per-thread has some tradeoffs
+	  (like calling ORB_init on each thread, activation of a servant
+	  is more complicated, etc.)
+	  Some of the problems, can be minimized, but they require
+	  even more careful analysis.
+	  For example,
+	  object activation can be simplified by using a global POA;
+	  the careful reader will wonder how could global POA be
+	  useful in anyway since it will require locks and thus
+	  introduce priority inversions again;
+	  some applications activate all their objects beforehand so
+	  locks in the POA are not always needed;
+	  other applications only activate a few objects after
+	  startup,
+	  so they can use a child POA with the right locking policy
+	  for the dynamic servants and the root poa (with no locking)
+	  for the majority of the servants.
+	</P>
+	<P>
+	  As the reader will note this is a delicate configuration
+	  option, the rule of thumb should be <B>not</B> to use
+	  ORB-per-thread unless it is really required.
+	</P>
+      </LI>
+      <LI><B>Collocation tables</B>
+	Why could the application what a non-global collocation table?
+	If objects are to serve requests only at a well known priority
+	the application can be configured with the ORB-per-thread
+	option, and the object is activated only in the thread (ORB)
+	corresponding to the desired priority.
+	But using a global table would subert the priority assignment
+	(because calls would run at the priority of the client).
+      </LI>
+    </UL>
+
 <P><HR><P>
 Back to the TAO <A HREF="components.html">components documentation</A>.
 
diff --git a/TAO/docs/releasenotes/TODO.html b/TAO/docs/releasenotes/TODO.html
index aaa340e042f..9b09eac6f47 100644
--- a/TAO/docs/releasenotes/TODO.html
+++ b/TAO/docs/releasenotes/TODO.html
@@ -29,6 +29,14 @@
     </CENTER>
 
     <UL>
+      <LI>Move the EC specific things out of this file to the ec.html
+	file.
+      </LI>
+
+      <LI>The IDL compiler gets confused with paths in NT, this may be
+	due to my changes to report errors correctly.
+      </LI>
+
       <LI>The do_static_call() and do_dynamic_call() methods should
 	use an array of void* (in the first case static and generated
 	by the IDL compiler);
@@ -372,6 +380,20 @@
 	Irfan) we need not worry about this until we find a use case for
 	it.
       </LI>
+
+      <LI>
+	The current implementation is optimal for hard-real-time
+	applications, but in some cases it may be desirable to follow
+	the normal execution path yet minize costs for collocated
+	calls.
+	An example would include an application that activates the
+	objects on demand.
+	It would be interesting to have a half-collocated stub
+	implementation, that will marshall the request and then
+	invokes the normal path on the "server" side, but without
+	crossing the kernel boundary. Ideally even the serialization
+	could be minimized or avoided.
+      </LI>
     </UL>
 
     <CENTER>