ChangeLogTag: Wed Jul 21 09:34:09 1999 David L. Levine <levine@cs.wustl.edu>

2 files changed, 102 insertions, 97 deletions

diff --git a/ChangeLog-99b b/ChangeLog-99b
index be5c7e36461..e51453750b1 100644
--- a/ChangeLog-99b
+++ b/ChangeLog-99b
@@ -1,86 +1,91 @@
+Wed Jul 21 09:34:09 1999  David L. Levine  <levine@cs.wustl.edu>
+
+        * examples/Shared_Malloc/test_position_independent_malloc.cpp (main):
+          removed declarations of unused argc and argv.
+
 Wed Jul 21 04:32:20 1999  Nanbor Wang  <nanbor@cs.wustl.edu>
 
-	* ace/Reactor.cpp:
-	* ace/Reactor.h:
-	* ace/Reactor.i:
-	* ace/Reactor_Impl.h:
-	* ace/Select_Reactor_T.cpp:
-	* ace/Select_Reactor_T.h:
-	* ace/Select_Reactor_T.i:
-	* ace/TP_Reactor.cpp:
-	* ace/WFMO_Reactor.cpp:
-	* ace/WFMO_Reactor.h:
-	* ace/WFMO_Reactor.i: The change was motivated by removing a race
-	  condition in TP_Reactor during shutdown.  There was a small time
-	  gap between a thread running TP_Reactor event loop checking its
-	  end_event_loop flag to the thread actually grabing the token in
-	  TP_Reactor.  Since the token return to its "normal" state after
-	  broadcasting, this thread has no chance to notice that the
-	  reactor has already been shutdowned and thus a deadlock occured.
-	  In order to fix the problem, we must keep a state indicating
-	  whether the reactor has been shutdowned or not in the reactor.
-
-	  An added benefit of adding this state is that every reactor now
-	  has its own run_reactor_event_loop which mimic the behavior of
-	  the static ACE_Reactor::run_event_loop but instead of working on
-	  the singleton reactor, the added function work on an instance of
-	  reactor object.  In fact, all event_loop control functions have
-	  been added.  They are named *_reactor_event_loop to
-	  differentiate their behavior.   These newly added function use
-	  the added state in the reactor to control the looping of event
-	  handling.  All run_reactor_event_loop methods take an extra
-	  argument of a function pointer.  The function will be called in
-	  every iteration if it is set.
-
-	  Notice that the singleton event loop control functions are still
-	  available.  Although these function merely forward the call to
-	  the singleton reactor's *_reactor_event_loop functions, you can
-	  still use them to control the "main" event loop.  In fact, it is
-	  required that you use these functions to run the main event loop
-	  because it facilitates Service_Configurator's "reconfigure"
-	  feature.
-
-	  All reactors now also have two extra functions namely
-	  "deactivated" which is used to query whether the reactor will
-	  handle more incoming event or not, and "deactivate" which is
-	  used to control this new feature.
-
-	  An side effect of the change is that, once a reactor get
-	  deactivated, calls to handle_events will return -1 immediately.
-	  You can use the "deactivated" method to check if there's
-	  actually an error in the handle_events method or it simply
-	  returned because the reactor has been deactivated.  This is also
-	  how the various "run_reactor_event_loop" handle the situation.
-	  Notice that this should not cause any backward compatibility
-	  problem becuase if a user is using his own end_event_loop flag,
-	  he will not (and should not) invoke any more handle_events after
-	  the flag has been set.  Also, if he is using the global
-	  run_event_loop methods (for controling singleton reactor,) they
-	  should still behave the same.
-
-	  To summarize the change:
-
-	  1. The run_event_loop control logic has been "pushed" down into
-	  each individual reactor.  The methods supporting the logic are
-	  defined in ACE_Reactor and are:
-
-	     run_reactor_event_loop ()
-	     run_alertable_reactor_event_loop ()
-	     end_reactor_event_loop ()
-	     reactor_event_loop_done ()
-	     reset_reactor_event_loop ()
-
-	  2. The origianl run_event_loop methods in ACE_Reactor are still
-	  working but they now use the run_reactor_event_loop methods in
-	  the implementation of the reactor.
-
-	  3. Reactors now keep a state to indicate handle_events should be
-	  called or not.  They can be controlled thru:
-
-	     deactivated ()
-	     deactivate ()
-
-	  methods.
+        * ace/Reactor.cpp:
+        * ace/Reactor.h:
+        * ace/Reactor.i:
+        * ace/Reactor_Impl.h:
+        * ace/Select_Reactor_T.cpp:
+        * ace/Select_Reactor_T.h:
+        * ace/Select_Reactor_T.i:
+        * ace/TP_Reactor.cpp:
+        * ace/WFMO_Reactor.cpp:
+        * ace/WFMO_Reactor.h:
+        * ace/WFMO_Reactor.i: The change was motivated by removing a race
+          condition in TP_Reactor during shutdown.  There was a small time
+          gap between a thread running TP_Reactor event loop checking its
+          end_event_loop flag to the thread actually grabing the token in
+          TP_Reactor.  Since the token return to its "normal" state after
+          broadcasting, this thread has no chance to notice that the
+          reactor has already been shutdowned and thus a deadlock occured.
+          In order to fix the problem, we must keep a state indicating
+          whether the reactor has been shutdowned or not in the reactor.
+
+          An added benefit of adding this state is that every reactor now
+          has its own run_reactor_event_loop which mimic the behavior of
+          the static ACE_Reactor::run_event_loop but instead of working on
+          the singleton reactor, the added function work on an instance of
+          reactor object.  In fact, all event_loop control functions have
+          been added.  They are named *_reactor_event_loop to
+          differentiate their behavior.   These newly added function use
+          the added state in the reactor to control the looping of event
+          handling.  All run_reactor_event_loop methods take an extra
+          argument of a function pointer.  The function will be called in
+          every iteration if it is set.
+
+          Notice that the singleton event loop control functions are still
+          available.  Although these function merely forward the call to
+          the singleton reactor's *_reactor_event_loop functions, you can
+          still use them to control the "main" event loop.  In fact, it is
+          required that you use these functions to run the main event loop
+          because it facilitates Service_Configurator's "reconfigure"
+          feature.
+
+          All reactors now also have two extra functions namely
+          "deactivated" which is used to query whether the reactor will
+          handle more incoming event or not, and "deactivate" which is
+          used to control this new feature.
+
+          An side effect of the change is that, once a reactor get
+          deactivated, calls to handle_events will return -1 immediately.
+          You can use the "deactivated" method to check if there's
+          actually an error in the handle_events method or it simply
+          returned because the reactor has been deactivated.  This is also
+          how the various "run_reactor_event_loop" handle the situation.
+          Notice that this should not cause any backward compatibility
+          problem becuase if a user is using his own end_event_loop flag,
+          he will not (and should not) invoke any more handle_events after
+          the flag has been set.  Also, if he is using the global
+          run_event_loop methods (for controling singleton reactor,) they
+          should still behave the same.
+
+          To summarize the change:
+
+          1. The run_event_loop control logic has been "pushed" down into
+          each individual reactor.  The methods supporting the logic are
+          defined in ACE_Reactor and are:
+
+             run_reactor_event_loop ()
+             run_alertable_reactor_event_loop ()
+             end_reactor_event_loop ()
+             reactor_event_loop_done ()
+             reset_reactor_event_loop ()
+
+          2. The origianl run_event_loop methods in ACE_Reactor are still
+          working but they now use the run_reactor_event_loop methods in
+          the implementation of the reactor.
+
+          3. Reactors now keep a state to indicate handle_events should be
+          called or not.  They can be controlled thru:
+
+             deactivated ()
+             deactivate ()
+
+          methods.
 
 Tue Jul 20 21:31:50 1999  Jim Rogers  jrogers@viasoft.com
 
diff --git a/examples/Shared_Malloc/test_position_independent_malloc.cpp b/examples/Shared_Malloc/test_position_independent_malloc.cpp
index 49f04565659..843310da32e 100644
--- a/examples/Shared_Malloc/test_position_independent_malloc.cpp
+++ b/examples/Shared_Malloc/test_position_independent_malloc.cpp
@@ -12,13 +12,13 @@
 ACE_RCSID(Shared_Malloc, test_multiple_mallocs, "$Id$")
 
 #if 0
-typedef ACE_Malloc <ACE_MMAP_MEMORY_POOL, ACE_Process_Mutex> MALLOC; 
+typedef ACE_Malloc <ACE_MMAP_MEMORY_POOL, ACE_Process_Mutex> MALLOC;
 
 // Default address for memory-mapped files.
 static void *base_addr = ACE_DEFAULT_BASE_ADDR;
 
 #if 0
-// Some dummy data 
+// Some dummy data
 struct Dummy_Data
 {
   int i1_;
@@ -27,7 +27,7 @@ struct Dummy_Data
   // ACE_Based_Pointer<Dummy_Data> next_;
 };
 
-struct Long_Test 
+struct Long_Test
 {
   ACE_Based_Pointer<long> bpl_;
   long array_[10];
@@ -40,13 +40,13 @@ print (Dummy_Data *data)
 #if 0
   ACE_DEBUG ((LM_DEBUG,
               "<<<<\ni1_ = %d, i2_ = %d, i3_ = %d\n",
-              data->i1_, 
+              data->i1_,
               data->i2_,
               data->i3_));
 
   ACE_DEBUG ((LM_DEBUG,
               "i1_ = %d, i2_ = %d, i3_ = %d\n>>>>\n",
-              data->next_->i1_, 
+              data->next_->i1_,
               data->next_->i2_,
               data->next_->i3_));
 #else
@@ -135,19 +135,19 @@ parse_args (int argc, char *argv[])
        )
     {
       switch (c)
-	{
-	case 'a':
+        {
+        case 'a':
           // Override the default base address.
           base_addr = (void *) ACE_OS::atoi (get_opt.optarg);
-	  break;
-	case 'T':
+          break;
+        case 'T':
           ACE_Trace::start_tracing ();
-	  break;
-	}
+          break;
+        }
     }
 }
 
-int 
+int
 main (int argc, char *argv[])
 {
   parse_args (argc, argv);
@@ -161,7 +161,7 @@ main (int argc, char *argv[])
                           "dummy_lock",
                           &options),
                   1);
-  void *data = 0; 
+  void *data = 0;
 
   // This is the first time in, so we allocate the memory and bind it
   // to the name "foo".
@@ -189,7 +189,7 @@ main (int argc, char *argv[])
     {
       // @@ Add a new print statement...
       // print ((Dummy_Data *) data);
-      ACE_DEBUG ((LM_DEBUG, 
+      ACE_DEBUG ((LM_DEBUG,
                   "data = %d\n",
                   *(long *) data));
       allocator->free (data);
@@ -209,8 +209,8 @@ template class ACE_Based_Pointer_Basic<Dummy_Data>;
 #pragma instantiate ACE_Based_Pointer_Basic<Dummy_Data>
 #endif /* ACE_HAS_EXPLICIT_TEMPLATE_INSTANTIATION */
 #else
-int 
-main (int argc, char *argv[])
+int
+main (int, char *[])
 {
   ACE_ERROR_RETURN ((LM_ERROR,
                      "sorry, example not finished yet\n"),