Go to the first, previous, next, last section, table of contents.

job control overview

The Muq multitasking model deliberately sticks fairly close to that of unix, both to avoid borrowing trouble in a tricky area by adopting a well-tested design, and to facilitate transfer of user expertise between Muq and unix.

A single flow of control within Muq -- a program counter plus a stack, if you will -- is termed a job. A job corresponds loosely to a unix process, except that it lacks a separate address space; A unix thread is in that respect a closer analogy.

Several jobs performing a single conceptual task (much like a unix pipeline) are grouped together into a jobset, corresponding to a unix process group. Jobsets provide us with a convenient way of (for example) stopping or killing all of the jobs in a pipeline, something which might otherwise be tedious and error-prone.

The group of jobsets executing for a single user connected via a single login are grouped toegether into a session, corresponding to a unix session. Sessions provide us with a convenient way of killing all the jobs associated with a login if the network connection is lost, and a place to record which jobset is currently titled to read and write interactively to the user -- the foreground jobset.

Muq jobs communicate and are controlled by a signal mechanism closely modelled on the unix signal mechanism, as well as via message streams which are loosely modelled on unix pipes, and via the db, which even more loosely corresponds to the unix filesystem.

Note: Muq signals are likely to change substantially as Muq is brought more into line with the CommonLisp exception-handling standard.

Go to the first, previous, next, last section, table of contents.