![[Contents]](contents.gif)
The program in Program Listing 3-8 illustrates Limbo threads:
implement Command;
include "sys.m";
include "draw.m";
sys: Sys;
Command: module {
init: fn(ctxt: ref Draw->Context, argv: list of string);
};
init(ctxt: ref Draw->Context, argv: list of string) {
sys = load Sys Sys->PATH;
for (i:=1; i<=5; i++) {
spawn func(i);
sys->print("%2d\n", i);
}
}
func(n: int) {
sys->print("%2.2d\n", n);
}
The
init function, Lines 11 through 18, creates a for loop that repeats five times, spawning the function func each time and printing the current iteration number. The function func also prints the iteration number passed to it by init. (The format flags added to the verb %d, 2 and 2.2, only serve to make it easier to distinguish which thread printed the number.)
The output from this program may look like this:
divine$ threadx 1 1 2 2 3 4 5 3 4 divine$ 5The order of the output is indeterminate, depending on such external factors as system load, the number of processors, and system scheduling policy. If run this program multiple times, the order of the output would likely be different each time. The last line in the sample output shows that, in this case, the first thread, created when the program started in
init, has exited and the prompt has returned before the last thread finishes.
The next section, Channels, shows how you can use channels to communicate between threads, including how to control thread synchronization with them.