Changeset 8297 for trunk/Ohana/src/opihi/doc/pcontrol.txt

Timestamp:

Aug 11, 2006, 4:52:37 PM (20 years ago)

Author:

eugene

Message:

divided test macros into macros by leveltests

File:

• trunk/Ohana/src/opihi/doc/pcontrol.txt (modified) (1 diff)

trunk/Ohana/src/opihi/doc/pcontrol.txt

@@ +1 @@
+
+2006.08.11
+
+I have nearly finished the conversion of pcontrol to use a background
+thread for monitoring the remote machines.  A few questions are still
+outstanding:  
+
+- currently, we are thread-safe for interactions with the stacks.  As
+  long as an operation is only working with a single job/host, and all
+  jobs/hosts are selected by pulling them from the stacks, there will
+  never be a contention between threads for the same job/host.
+  However, are there problems for commands which require a specific
+  job or host but are unable to find it because the job/host may be in
+  flight from one stack to another.  
+
+- The CheckIdleHost command needs to join a job and a host.  In this
+  case, it is necessary to lock the job PENDING stack while searching
+  for a job to give to a host.  The host is pulled off of the IDLE
+  stack before being past to CheckIdleHost.
+
+o CheckIdleHost currently does not have a way to send a WANTHOST job
+  to any host other than the WANTHOST.  What should the rule be by
+  which a job is run on an alternative machine? (partial fix)
+
+- we are not starting any of the job or host timers?
+
+2006.08.09
+
+working on pcontrol CheckSystem background thread.  One thread runs
+the readline interaction and performs all of the user commands.  The
+second thread runs the CheckSystem loop and tests the hosts and jobs.
+We need to be sure these two do not interfere with one another.  Here
+is a list of all of the user commands and the ways in which they
+interact with the Job / Host queues:
+
+
 
 2006.08.04
 
-pcontrol get a large delay every time it tries to connect to a host.
+pcontrol gets a large delay every time it tries to connect to a host.
 this is because the readline interrupt has to wait for the connection
 to complete.  I probably need to fix this by using a threaded model