© Jørgen Steensgaard-Madsen, Copenhagen, 2006
Processes and connections                                                  

Processes, pipes, and other program notions that are well-known from Unix operating systems (with specifications later by POSIX) are supported by some operations that can be seen as members of objects of class unix :
[ unix[Members OF PIPE, PID ...] ]

A values of type PIPE represents the kind of communication channel called a pipe. A value of type PID is called a process id

Elements of Members

Clause   Init of operation child
Application of child spawns a process that evaluates Init according to POSIX specifications. The spawned process may choose to run a program by application of exec :
Clause   Access of operation source
Evaluates Access after an input stream has been generated and bound to the given pipe
Clause   Access of operation dest
Evaluates Access after an output stream has been generated and bound to the given pipe
Clause   Con of operation run
The run operation in a sense makes a simple thing difficult and makes something strange possible. A shell simply can connect processes and their program into a pipeline, whereas connecting them in a ring structure is impossible. This is not the place to argue rationally for or against such a ring structure.
A typical POSIX process depends on a kind of I/O ports called file descriptors being bound by an environment. Three such ports exists and a shell is responsible to connect these ports appropriately to devices or channels (e.g. pipes).
Nothing prevents a process to assume more than three I/O ports to be bound by an environment. The problem is the environment, and the run operation might be used to express an appropriate environment.
An example can show how establish a ring structure with just two elements:
{ unix;
    with (newpipe) a;
    with (newpipe) b;

        # executes ... in process P1

        # executes ... in process P2

P1 executes a program that assumes four I/O ports to be bound, whereas P2 depends on the standard three. File descriptors in the two processes correspond to element numbers in the lists given as second argument in the applications of run.
P1 writes its standard output (file descriptor 1) over pipe a which is read as standard input in process P2. P1 also receives data at file descriptor 3, bound to pipe b and used for standard output by process P2.
The operator < is bound to special meanings for the evaluation of Con. Hopefully readers will see it as giving an sense of direction of data flow at a port. It is overloaded so that different kinds of connections can be made: data streams known to the process applying run, files known by names, and pipes.
A technical remark: the evaluation of Con takes place in a spawned process that will execute the program represented by the first argument given to run. The signatures are simple:


·Demo language
Implementation tool

General properties

Somefix operators
Predefined type operators
Mutable variables
Functions for mathematics
File operations
·Processes and connections
Misc. utilities
New type operators
Top-level entities

File translated from TEX by TTH, version 3.33.
On 18 Oct 2006, 16:47.
SourceForge.net Logo