The main method of communication between child and parent tasks is through explicit 'signal' events. This mechanism allows the child task to send a message to the parent, and vice versa. This works as follows:
In both cases, the Signal method optionally takes an
argument, which is any APL array (or an APLX overlay created using
For example, suppose a child task is being used to carry out a time-consuming calculation. It starts by awaiting a signal to indicate that it should do the calculation, with the argument to the signal being the data to work on. When it has completed the calculation, it sends a signal back to the parent with the answer. The following sequence indicates how this might be done.
First we need to do some setup. The parent task attaches a callback to the child task object:
∇CALCDONE  'The answer is ' ⎕WARG ∇ ChildTask.onSignal←'CALCDONE'
This will cause the
Similarly, the child task attaches a callback to its System object, waiting for a signal to indicate that it should carry out the calculation:
∇DOCALC;RESULT;DATA  DATA←⎕WARG  RESULT←RUNMODEL DATA  '#' ⎕WI 'Signal' RESULT ∇ '#' ⎕WI 'onSignal' 'DOCALC' ⎕WE ¯1
This will cause the
To carry out the calculation, the parent signals the child, and then processes
events (if it is not already running under
ChildTask.Signal THEDATA ⎕WE ¯1
This triggers the child task to run the
The answer is 42
In a real example, the parent task would be responding to other events (for example,
user-interface events), and there might be a number of child tasks each
simultaneously working on a different run of the model. If you have multiple child tasks running,
you can use the task ID (
There might also be a queue of signals waiting to be processed on either side. Note that there is a limit to the number of events which can be queued, typically around 200 events. If this maximum is exceeded, the oldest events are thrown away.
Copyright © 1996-2010 MicroAPL Ltd