Making FEEL

The kind of system you can make depends on the combined capabilities of your operating system and processor. has been developed in a solely Unix environment and this has considerably warped its view of the world. So far, has only been ported to different versions of Unix. A particular feature of is support for multiple threads of control. Whether these do actually execute concurrently depends on the host system, but, in principle, it should be possible to develop a program using threads on one system—perhaps a uni-processor simulating concurrency—and later execute the same program on a multi-processor or a distributed processor to achieve the same net result.

Broadly speaking, can be made in any of three main configurations ...

Generic
Under the ``any'' machine configuration, attempts to be a fully portable ANSI C program. Because there is no reliably portable method of implementing threads in C, the thread operations in this mode are not available and only a serial version of remains. This mode is most suitable for getting started quickly and also the most sensible place to begin for porting to new architectures or operating systems. Memory use is minimised which may benifit smaller machines such as PCs or any system where memory is at a premium.

BSD
This (badly named) configuration mode requires that a stack switching operation be available for to use. Given this code (typically a few lines of the local assembler), the thread operations become available with the limitation that only one thread is run at a time. This mode allows programs to be written in terms of threads which may later be run in parallel without alteration. This mode is most useful for allowing the developing multi-threaded applications under unsupportive operating systems such as BSD 4.2 or 4.3.

System V
This configuration requires that stack switching code be available along with the standard System V shared memory manipulation primitives. Given these things becomes a truly parallel multi-threaded system using the following model: on start-up a piece of shared memory is allocated, then forks as many times as there are physical processors in the host machine (this behaviour may be modified). Each of these forked processes runs the scheduler, running threads from the pool in the shared heap. Each such thread is run to conclusion—unless it yields control, in which case it will be returned to the pool. More processes may be forked than existing processors to simulate truly parallel operation on uniprocessor systems such as Suns running SunOS 4.1.