FastForkDoc.tioga
Created by Christian Jacobi, May 7, 1986 4:35:37 pm PDT
Christian Jacobi, April 19, 1993 10:01 am PDT
THIS HAS BEEN REPLACED BY ForkOps.df
FastFork, PeriodicalFork
CEDAR 7.0 — FOR INTERNAL XEROX USE ONLY
FastFork, DelayedFork, PeriodicalFork
Christian Jacobi
© Copyright 1989 Xerox Corporation. All rights reserved.
Abstract: FastFork re-implements the language fork with a cache; It is in average much faster then using the language fork directly.
DelayedFork allows to fork a procedure delayed.
PeriodicalFork allows to repeatedly fork a procedure.
Created by: Christian Jacobi.
Maintained by: Christian Jacobi <Jacobi.pa>
Keywords: Fork, Multi-programming, Multi-processing
Both, the definitions and the implementations are well documented using comments.
FastFork
Fork: PROC [proc: PROC[REF], data: REF←NIL];
Like TRUSTED { Process.Detach[FORK proc[data]] } except
1) faster ! (in average)
2) proc starts execution on priority Process.priorityForeground
Why this is faster than the language FORK:
It assumes the language FORK has to initialize a stack frame; but this Fork most often doesn't need to do this.
This package has a small pool for processes. If on fork the pool is not empty a process is reactivated instead of created. This algorithm also works if the number of processes exceeds the pool size: Processes in excess of the size pool size are keept alive for few tenths of a second before discarding.
This a) saves initialization times, and, b) maybe might improve VM paging behaviour by using a LIFO
Caveats
Like using the language FORK:
-This module does not prevent clients from forking too many processes.
-No nested procedures. However, this module would crash more friendly.
Consider also using DelayedFork.ForkSoon with a delay of zero; this will also fork in this time period but will limit the number of running processes (DelayedFork.ForkSoon is actually implemented on top of FastFork.Fork.)
DelayedFork
ForkSoon:
PROC [ms:
INT𡤀, proc:
PROC[
REF], data:
REF←
NIL];
proc will be forked after approximately ms milliseconds
time very approximate (see below) !
The forked proc starts execution on priority Process.priorityForeground.
Forked procedures are serialized using a few processes (using more processes if the queue is growing); this saves process initialization time and averages processor load. It also reduces the number of processes at any particular time, however it does not give an absolute guarantee against forking too many processes. (Explicitely: procedures which wedge won't return the underlying process.)
Time delay limitations:
Time approximated to some power-of-two of about a tenth of a second. The fork happens after two ticks of the approximated interval to guarantee a wait period of at least one interval.
A time -1 causes an immediate fork and increases the number of real processes executing procedures until some process becomes idle again. A time of 0 ensures that at least one process is executing the forked procedures.
Procedures which will wait long times on CONDITION's should not be forked with delay times less than 100 milliseconds because this might prevent other procedures from execution for this time interval. (No problem for delays of more then 100 milliseconds: Procedures which are delayed for more then 100 milliseconds will not delay urgent procedures; but the delay for less urgent procedures is limited.)
No nested procedures.
PeriodicalFork
Register:
PROC [ms:
INT, proc:
PROC[
REF], data:
REF←
NIL];
proc will be called approximately once every ms milliseconds
time very approximate !
Unregister:
PROC [proc:
PROC[
REF], data:
REF←
NIL];
stops calling this proc/data closure soon
UnregisterSelf:
PROC [];
stops further calls on this closure
must be used by proc called from PeriodicalFork only
this is implemented with signals and won't work if UNCAUGHT is catched
Allows to repeatedly fork a procedure.
The forked proc starts execution on priority Process.priorityForeground.
Calls for every registration are synchronized: a procedure will not be called again unless the previous call returned.
Time intervalls between forks are approximative.
Time interval limitations
Minimum interval about a tenth of a second; depending on processor speed.
Interval approximated to some power of two of minimum interval
Motivation
Many packages have a process which periodically does some work. By using this mechanism such packages can avoid permanently allocating a PROCESS resource. Maybe this might even improve VM paging behaviour a little.