prev back next

Processes

Smalltalk allows multiple lightweight processes (also called threads or tasks) to execute pseudo concurrently. These run within the same address space (in one heavy weight Unix process) and can communicate via shared objects. Process scheduling is priority driven, where scheduling is implemented fully in smalltalk (i.e. all algorithms are open and can be changed if there is a need to do so).

Each process has its own automatically growing stack which is protected against overflow. No stack size definition is needed at process creation time - the system will allocate additional stack memory in reasonable small increments. Stack overflow can be cought (see exceptions) and handled gracefully (it is even possible to restart or continue with more stack space after such an exception).

Also, multiple processes can be debugged simulatiously (using the symbolic Debugger) - even while executing concurrently.

The windowing interface makes use of processes, by executing each view in a separate process. This means, that other views are not locked up by one view being debugged or busy (which is the case in pure event driven systems).

The interresting classes are:

Process

Class Process represents a thread of control in smalltalk. An arbitrary number (limited by memory) of processes can execute concurrently within a smalltalk system. These processes (also called threads or lightweight processes) are not implemented as Unix processes, but instead are created, managed and scheduled by smalltalk itself. They all run in the same address space; therefore, the same objects can be accessed by different processes.
Typical uses: Read using processes for detailed information on processes.

ProcessorScheduler

Class ProcessorSchedulers sole instance (named Processor) is responsible for scheduling among running processes. In contrast to other smalltalk implementations, scheduling is done at the smalltalk language level. This allows for different schedulers to be implemented if required.
Typical messages sent to Processor:

Semaphore

Semaphores are used for process synchronization, nonBusy waits and mutual exclusion of processes from critical regions. A process can wait on a semaphore (and thereby be suspended from execution) until the semaphore is signalled (which resumes execution of the process).
Semaphores can also be installed for being signalled on I/O availability or timer expiration.
Typical use: The I/O and timer messages are low level protocol; use the protocol provided by Delay and ExternalStream for portability.

Delay

Class Delay wraps the above timer based suspend into a portable interface.
Typical use:

Copyright © Claus Gittinger Development & Consulting, all rights reserved

(cg@ssw.de)