processmanager - singular object, scheduling user-defined
Scheduler for 'IOProcess' objects written in Simula. This
class reacts on external events (such as data available on a
file) and sends corresponding Simula events to related
IOProcess object. This class also manage 'context switches'
using Simula operations call/detach.
See the users manual in simioprocess.html" >ioprocess.ps
Boris Magnusson, Lund Institute of Technology.
PriorityQ class ProcessManager;
IOProcess objects must be 'registered' in order to be
managed by this scheduler. When processes ready to run are
avilable they are activated. When there are no such
processes this schedluer makes the Simula program sleep
until someting happens (input avilable or timer goes off).
When there are no open files watched by a IOProcess and
there are no timers set, the scheduling finishes. CancelAll
all is a 'soft' terminater allowing those who need to
cleanup to do so. TerminateAll is a killing all IOPorcesses
Init: At least one IOProcess must be started before 'Run' is
'Run' works as a scheduler and 'Call's other IOProcess
: (Run / RunningProcess / CancelAll / TerminateAll)*
USER ACCESSABLE OPERATIONS
Register P as a process that can be scheduled. P is an
object of a subclass of IOProcess (see below).
Forget about P - It can not be scheduled again unless re-
registered. Terminated IOProcess objects are automatically
Give control to this ProcessManager -- it will schedule
processes and call them as appropriate. Run will finish when
When a call to Run is finished the execution will continue
after the call to Run.
ref(basicProcess) procedure RunningProcess;
return a reference to the currently executing process.
(Mainly intended for use in implementation of scheduling
primitives such as Semaphore and Monitor. Should not be
neccessary to use in the applications).
Broadcast CancelEvent:s to all IOProcesses that have called
EnableCancelEvent. Besides this the PMG does not do
anything exceptional. Processes with EnableIO- Events should
as a result call DisableIOEvents when terminating actions
are done. As a result of broadcasted CancelEvent:s there
should after a while be no processes left in the Ready
state, with IO-Events enabled or with timers set, so the
terminating condition of the Run-procedure should be
fullfiled. Execution is then resumed after the call to Run
in 'the main program'. CancelAll can be called many times
if the processes refuses to die... If the processes are
left in a consistent state a new call to Run should be
Emergency termination of the Run-call. Control is
immediately transferred to the point after the call to Run
in 'the main program'. There are also a number of
operations in the ProcessManager that are called from class
Process and should not be called by the user code directly.