Path: utzoo!attcan!telly!lethe!torsqnt!jarvis.csri.toronto.edu!mailrus!wuarchive!brutus.cs.uiuc.edu!usc!venera.isi.edu!raveling
From: raveling@isi.edu (Paul Raveling)
Newsgroups: comp.sys.hp
Subject: Re: rtprio for X
Message-ID: <9825@venera.isi.edu>
Date: 22 Sep 89 18:26:32 GMT
References: <3140004@hpldsla.HP.COM> <5283@ucdavis.ucdavis.edu>
Sender: news@venera.isi.edu
Reply-To: raveling@isi.edu (Paul Raveling)
Organization: USC Information Sciences Institute
Lines: 41

In article <3140004@hpldsla.HP.COM>, cjames@hpldsla.HP.COM (Craig James)
writes:
> 
> It's hard to see how that is possible with real-time capabilities.
> After all, if I start up a process that runs until it explicitely gives up
> the CPU, and that process goes into an infinite loop, there is no escape but
> to reboot.
> 
> Perhaps the system you described didn't provide such abilities?

	In such a case the machine would go CPU-bound, but nothing
	drastic would happen unless the looping process was a crucial
	system process, such as a device driver.

	Processes in loaded applications were offspring of an Exec process,
	which was the first process created in each job except the kernel
	job.  The Exec ran as a VERY high priority process, and its offspring
	were restricted to priorities below those of the Exec and all
	system processes other than the Idle process.

	The normal way out of the loop was for the user to hit control-C
	on the keyboard.  The terminal i/o process for the associated
	terminal signalled the Exec, which then preempted the looping
	process.  For ^C the Exec froze its offspring, including the looper,
	and resumed accepting commands from the terminal.

	The usual next command was "MEND", which stood for Multi-Environment
	Native Debugger.  This allowed usual sorts of debugging operations
	on the job's processes, including single-stepping the loop or
	patching data up and resuming execution.


	For a different answer, a prior incarnation of the same kernel
	architecture also implemented time slicing.  This this proved
	unnecesary in EPOS' event-driven real time environment, but
	would be appropriate in a more system with more diversified use.
	

----------------
Paul Raveling
Raveling@isi.edu