Changeset 7952 for trunk/Ohana/src/opihi/doc/pantasks.txt

Timestamp:

Jul 23, 2006, 3:05:21 PM (20 years ago)

Author:

eugene

Message:

adding working threads to server/client mode

File:

• trunk/Ohana/src/opihi/doc/pantasks.txt (modified) (2 diffs)

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

@@ +1 @@
+
+- todo:
+
+  - create the processing threads:
+    - check tasks
+    - check jobs
+    - check controller  
+    - load inputs
 
 - additional issues:
-
-  - missing dependency for shell.h?
-  - should not return an error message in client if command is not found
   - server input needs to place files for input on a stack which is 
     actually loaded by the RunScheduler loop
@@ -10 +15 @@
     be running multicommand, but it probably does not hurt.
     (the client is not allowed to send ';' to the server)
-  - the multicommand needs to be available in the 'for' and other loops
-    this probably means unifying the client and non-client forms.  
-    how does multiclient get the value of the server?  I tend to use
-    globals for things like that, which is probably not the best 
-    practice.  is the client form of the tool generic? are there other
-    circumstances which would use a client/server beyond pantasks?
-    maybe pcontrol?  
 
-    the two pieces of information which need to be carried to the
-    multicommand and command functions in client/server mode are the 
-    server socket and the verbosity of the error messages.  these could
-    be defined on startup with globals and an init function of some sort.
+  - pantasks input: this passes an 'input' command to the server, which
+    performs the input in a different thread.  is this the same thread
+    as the scheduler loop?  another option within the scheduler loop?
 
-I need to do some serious work on the output messages in order 
-to support the client/server interactions.  In client/server mode,
-all of the output messages to be sent back to the client need to be
-saved in a buffer and then pushed back to the client after the command
-is executed.  Currently, I can select only the output file pointer.
-this is not sufficient.  I need to supply a function which will write to 
-an internal buffer until a 'dump' function is called, or something
-equivalent.  
-
-in client/server mode, the commands issues by the client (except as noted 
-below) all return immediately.  The output produced by those commands
-is saved by the server until the command is finished, then the
-resulting buffered data is pushed back to the client.  There a few
-commands which behave a bit differently.  these commands are in the
-background thread of the scheduler.  the resulting output is sent to
-the logger device of the scheduler rather than back to any specific
-client.  should there be a way for the client(s) to examine the
-scheduler output? 
-
-- pantasks input: this passes an 'input' command to the server, which
-  performs the input in a different thread.  is this the same thread
-  as the scheduler loop?  another option within the scheduler loop?
-
-- run