Path: utzoo!utgpu!watmath!att!bellcore!texbell!wuarchive!wugate!uunet!mcvax!hp4nl!phigate!philmds!leo
From: leo@philmds.UUCP (Leo de Wit)
Newsgroups: comp.sys.atari.st
Subject: Re: Towards a real, somewhat compatible multiTASKING TOS
Keywords: TOS, Multitasking, constructive ideas and proposals, future versions
Message-ID: <1077@philmds.UUCP>
Date: 17 Aug 89 10:01:55 GMT
References: <877@per2.UUCP>
Reply-To: leo@philmds.UUCP (Leo de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 120

In article <877@per2.UUCP> dag@per2.UUCP (Daniel A. Glasser) writes:
|There's been a lot of chatter about multitasking on the ST, but no real
|concrete proposals.  It seems that many of the people in the debate are
|not aware of the difference between a multitasking system and a multi-user
|system.

I have a real and very concrete proposal. It's the multitasking system I'm
building right now. Read on.

|[]
|Changes to TOS for application driven multitasking might include the following:
|[]
| 1)	An extended basepage which contains entries for various hard and
|	soft exception vectors.  Notably, there should be a termination
|	vector, divide by 0 vector, buss-error, address error, critical
|	error, illegal/invalid instruction, break-point, etc.  A TOS call
|	to set the vectors (Set Exception Vector) already exists, and
|	could be modified to use the extended basepage.  The entries in
|	the extended basepage vector table would have three reserved values:
|	-1L means use the parent process value for this vector, -3L means
|	use the system default routine for this vector, 0L means ignore
|	this exception, any other even value is taken as the address of
|	an exception routine to be jumped to in the case of the exception.
|	All other odd values are reserved.

My solution uses per process an array of 32 exception vectors, which
resemble the standard set of signals for a BSD type UNIX system, a
signal mask to indicate which signals are currently being blocked,
and a set of 'signals to be delivered'.
Signals can be ignored, defaulted, and set to user-supplied routines.
Instead of Setexc() I introduced calls like signal() and kill() to set
and invoke signals (they are triggered via an extra GEMDOS function).
The signal mask is inherited from the parent by child processes, which
means that ignored signals stay ignored (unless the child explicitly
calls signal()). Not-ignored signals are defaulted. This is all
conforming standard Unix. Perhaps I could add some of the suggestions
you made (when it doesn't violate my sense of a clean system; some
ideas sound really nice).

|
|	This vector table would allow programs that set exception vectors
|	to abort abnormally without fear of bringing the system down, and
|	allow multiple programs to set exception vectors for when they are
|	the active task.  The vector table could have more or different
|	entries than are in the system table now, for example, a control-c
|	vector, an I/O Timeout vector, a message-received vector, etc.

I intercept the keyboard interrupt and store occurences of ^C,^\ and
^Z.  These are passed to the running program as SIGINT (default
action:  terminate), SIGQUIT (default action: terminate with coredump)
and SIGTSTP (default action: stop the process - it can be restarted
later).  There is no notion yet of fore- and background; when it's
there, only the foreground job(s) can receive these keyboard-generated
signals. Also SIGALRM has been implemented, with corresponding
functions/system calls sleep(), pause(), alarm().

|	
| 2)	A new TOS call to send a signal to a process based on its ID.

I use one new TOS call to implement several new functions; the unused
0x4d. The first argument is the request. 2) would be kill().

|
| 3)	A new TOS call to unschedule a process until it receives a signal.

This is pause().

|
| 4)	An extensible stream device list, similar to the extensible
|	block device list, allowing serial devices to be added and used
|	in the same manner as the standard streams.

Pipes and perhaps semaphores, messages queues are planned.

|
| 5)	A new TOS call to schedule a signal to a process at some delta-time.

Don't know what you mean here exactly, but it could be alarm().

|
| 6)	An extension of the Mshrink TOS call to conditionally grow an allocated
|	block of RAM.

Don't know what you mean by conditionally here; I'd say if you don't want
the grow, don't do the call.

|
| 7)	An extension to the Malloc command to return the size of the largest
|	contiguous available block of RAM.

This is already there: call Malloc with -1 as argument.

|
| 8)	An extension to the TOS Pexec function to start a task and continue.

Indeed; also implemented. A priority can be given to the started task;
priorities may be modified by the getpriority() and setpriority() calls.

|
| 9)	The ability for an interrupt handler to access the process context
|	of a task.

What do you mean by this: its own process context, or some other process's
context; what would you want to do with it?

|[]
|This is just to get the ball rolling.  Let's see some constructive ideas
|on what a TOS 3.0 might look like.  If we can get a good enough unified
|collection of ideas, maybe the folks in Sunnyvale might use some of it.
|If the ST commercial software development community publicly buys into
|the ideas which may break lots of existing software, we might see some
|real progress.

What you will need also in a multitasking environment is some means of
restricting the amount of memory supplied to a program; I found out
many programs just don't Mshrink, so you need to control this too.
B.T.W. thanks for some nice ideas, maybe someone else wants to add to
this discusson too?

    Leo.