Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!bbn.com!mips2!granite!kittlitz
From: kittlitz@granite.cr.bull.com (Edward N. Kittlitz)
Newsgroups: comp.os.misc
Subject: Re: a question about Multics
Keywords: multics
Message-ID: <1991Jan11.141003.2794@granite.cr.bull.com>
Date: 11 Jan 91 14:10:03 GMT
References: <1991Jan10.185854.3071@murdoch.acc.Virginia.EDU> <1991Jan10.211253.24868@Think.COM>
Organization: Bull HN Information Systems Inc.
Lines: 55

In article <1991Jan10.211253.24868@Think.COM> barmar@think.com (Barry Margolin) writes:
>Also, I think this example uses a Multics feature that was never fully
>implemented: call-out.

Typing as someone who successfully implemented a Multics subsystem which
used call-out (more privileged, but not actually supervisor ring
invoking a program in a less-privileged ring), I must disagree.
The Batch Job Processor (BJP) consisted of ring4 code
which obtained "jobs" from a card reader. Each job consisted of a language
directive (C, Fortran), source code, and optional data. If I tell
you that there were two card readers, you will realize that I am not joking.

All first-year students used cards, as terminals were scarce. The goal
(met) of BJP was to increase the throughput of these jobs by eliminating
the standard overhead of creating a process for each one. I recollect
process creation overhead as being a significant fraction of a second,
while the actual compile/execute time was often less than that.

I can't remember whether I did the compilation in ring4 or ring5.
(Compilers being relative well-behaved, I might have "trusted" them.)
At any rate, there was a timer set for each job. The program was
actually executed in ring5. If the program was well-behaved, it returned
to its ring5 caller (the equivalent of crt0), which returned to ring4
using a gate. The ring5 environment was re-initialized (all newly
created static tossed out, etc), in preparation for the next job, and
the output file was queued for printing.

It's been over 10 years, but I was able to cope with common errors
such as an invalid address (null pointer reference) or excessive
CPU consumption. I may have had to use Multics "static condition handlers"
to ensure that ring4 got control of a signal caused by ring5.

(Greg B. Lindahl) writes:
>>1. The student program could call another segment elsewhere to perform
>>   the actual work, allowing him to do the work after the deadline.
>>2. The student program could call another student program to do the
>>   work. This is the more interesting option ;-)

I believe it is possible to prevent access to other segments, but
it may require substantial effort. You would then also need to supply
your own ring5 version of system call gates, such as hcs_. The
gate would transfer to ring4, and permitted calls would be reissued
to the real hcs_. e.g. initate-segment and change-search-rules would
be constrained.

The teacher must also determine that the program is doing real work,
and not (for example), simply writing out some correct answers.

-----
E. N. Kittlitz	kittlitz@world.std.com / kittlitz@granite.cr.bull.com
Contracting at Bull, but not alleging any representation of their philosophy.
-- 
-----
E. N. Kittlitz	kittlitz@world.std.com / kittlitz@granite.cr.bull.com
Contracting at Bull, but not alleging any representation of their philosophy.