Processes

[kddlab!atr-la.atr.co.jp!myers@uunet.UU.NET (John K. Myers)]

This is 1) a request for information, and 2) a general flame on the
state of the documentation on processes.

It's time to play with processes.  There are only a handful of basic
operations that need to be supported:
1.  Fork off a process and never look at it (provided by process-run-function);
2.  Make a process and return a pointer to it (make-process)
3.  Have a process decide to go to sleep by itself and then wake up
    a specified time later, without consuming resources (sleep)
4.  Have a process decide to block itself and not consume significant
    resources until it is unblocked.
5.  Have a separate process order a specific process to block and
    not consume resources until it is unblocked.
6.  Have a separate process order a specific blocked process to unblock.
7.  Have a separate process order a specific process to kill itself
    permanently.

4 appears to be implemented by (process:block-process "Blocked" T),
which gives a verify-function of T.  Apparently, if the verify-function
is NIL, even if the process is unblocked, the process will not start.
4 could also be implemented by (process:wait-forever), the difference
is unclear.
  5 appears to be implemented by (process:disable other-process).
  6 appears to be implemented by (process:enable other-process) as the
best choice.  It is unclear whether this is guaranteed to get the
process running, or whether other conditions must be fulfilled.
6 also appears to be implemented by process:wakeup, process:force-wakeup,
and process:wakeup-without-test.  The difference between these is
quite unclear, although, given a choice, I'd guess process:force-wakeup
sounds like what I want.  process:wakeup is described as, "Evaluates
the verify function of process."  Presumably this has some side-effect,
such as changing the processor's state into RUNNABLE if the function
evaluates to non-NIL; it is hard to see why I would want the value of
a function in a master process, and why a function evaluation function
would be called "wakeup".  The side-effect is not described.
"wakeup-without-test" amazingly "wakes the process up" without testing
the function, and then tests the function, possibly without waking
the process up (if the function tests negative).  Ah, the Zen of
Symbolics programming.  And yet, this is the clearest description of
the three.  Apparently the function is not tested in the calling process,
but it is tested in the subject process.  How this differs from
"wakeup" is unclear.  "force-wakeup" "wakes up Process".  What happens
to the verify function?  Is it ignored?  Since the other wakeups were
so worried about the verify function, is "force-wakeup" only the first
half, and I have to call "wakeup" to evaluate the function in order
to get the process to run?  What happens if the verify function is negative?
  7 appears to be implemented by either process:abort (the weak version),
or process:kill (the strong version).  It is unclear how to ensure that
a process stays dead and does not come back from the grave, since 
process:kill warns that Reset (process:reset?) will still work...
  5 also appears to be implemented by process:flush, which "forces a
process to be blocked", without changing the state of its computation.
This smells like a lose, though, with a name like "flush".  Unclear
how to unflush a process, or difference between flushing and blocking,
aborting, or killing.  Apparently flushing is like blocking except
flush requires a process:reset in order to keep running (which DOES
change the state of its computation--a reset loses all local variables).

2,5, and 6 also apparently can be implemented by something like:
(defvar SLAVE-RUNNING T)
;Make process
(setq slave (process:make-process :initial-function my-slave-function
                                  :run-reasons '(SLAVE-RUNNING) ))
;Process starts out running automatically
..
;Block the process from outside
(setq SLAVE-RUNNING nil)
..
;Restart the process from outside
(setq SLAVE-RUNNING T)
;Is a process:wakeup necessary here?

although I have no confidence that I've gotten the idiom right.

Question:  Can Those Who Know verify that process:disable, 
process:enable, and process:kill are generally the right things to do?

Flame can be found in following message.

Thank you very much,
  John Myers~~           myers@atr-la.atr.co.jp