dag@per2.UUCP (Daniel A. Glasser) (08/17/89)
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.
Multi-tasking does not imply multi-user. A version of TOS that could do
multi-tasking need not have any memory protection hardware beyond what is
already in the basic ST. Task swapping would not be required. Context
switches would be relatively clean and efficient. Many existing programs
would not work well as background tasks because they go directly to the
hardware or make assumptions about the "unused" memory, others would run
in the background without modification. Even those which could not multitask
could be run as single tasks. It may be useful to note that I've seen
multitasking systems on 8-bit processors with no MMU and less than 64kb
RAM, and that the original version of UNIX was developed on a machine
with even less RAM and no MMU. 5th Edition Unix was running on the
DEC LSI-11/02, which had no MMU and 58Kb of RAM total.
Changes to TOS for application driven multitasking might include the following:
(This is not an exhaustive list. I would think that programs that use the
multitasking environment would have a different magic number, and an
extended process header (which would make sense because of what the magic
number actually is anyway), and the TOS program load code could determine
if the task can be multitasked or not. Older versions of TOS would not
execute multitasking programs.)
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.
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.
2) A new TOS call to send a signal to a process based on its ID.
3) A new TOS call to unschedule a process until it receives a signal.
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.
5) A new TOS call to schedule a signal to a process at some delta-time.
6) An extension of the Mshrink TOS call to conditionally grow an allocated
block of RAM.
7) An extension to the Malloc command to return the size of the largest
contiguous available block of RAM.
8) An extension to the TOS Pexec function to start a task and continue.
9) The ability for an interrupt handler to access the process context
of a task.
10) Change TOS blocking I/O operations so that they reschedule rather
than busywait.
11) Change TOS block device I/O operation so that they reschedule rather
than busywait.
12) Add a mechanism to TOS to gain/release exclusive access to a stream.
I've not gotten into the changes to make the file system robust in a multi-
tasking environment or the changes to the GEM code that would be required.
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.
--
_____________________________________________________________________________
Daniel A. Glasser One of those things that goes
uwvax!per2!dag "BUMP!!!(ouch)" in the night.
---Persoft, Inc.---------465 Science Drive-------Madison, WI 53711-----------gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl) (08/17/89)
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. No, there is one concrete program out there (Beckmeyer's stuff) and Leo is working on another real system. And there are lots of people talking past each other about multitasking and multiuser and all that. Keep in mind that there is NO EASY WAY to add multitasking to GEM (the graphics part) such that you can have several gem applications going, but with a multitasking GEMDOS (which provides functions like MS-DOS), you could write a desk accessory that would allow you multiple multitasking CLIs along with 1 GEM application. It doesn't matter whether this is the most optimal solution, because this is what can be done without totally re-writing GEM. :-) :-) ------ Greg Lindahl gl8f@virginia.edu I'm not the NRA.
leo@philmds.UUCP (Leo de Wit) (08/17/89)
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.
david@bdt.UUCP (David Beckemeyer) (08/19/89)
OK, I've listened to all this long enough! 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. [ stuff deleted ] > >Changes to TOS for application driven multitasking might include the following: [ list of new TOS features deleted ] Has anyone ever heard of Micro RTX? RTX implements the things Daniel and others have listed, and more. RTX is multitasking TOS, with many other multitasking extensions too. I'm amazed how someone can bring up multitasking and there can be this much discussion, yet in real life people don't even know what's already out there. People start saying how badly they want multitasking, but when I offered to make RTX binary free if someone would just write a simple application to give away with it, nobody was interested. Everybody wanted me to give away RTX, but noone would offer to spend a liitle of their own precious and valuable time and energy to make it happen. Anyway if you people are really interested in multitasking TOS, the offer still stands. If someone will show they are serious and write a RTX based application program (e.g. a nifty freebie shell that knows how to fork jobs, maybe use interprocess communications, print spooler, etc.), I will release the RTX binaries for public consumtion, along with this program. This seems fair to me. But no, most of you will just wait for somebody else to do the work for you. Not Leo though. Here's a man who does more than talk (as far as I can tell). -- David Beckemeyer (david@bdt.UUCP) | "I'll forgive you Dad... If you have Beckemeyer Development Tools | a breath mint." 478 Santa Clara Ave. Oakland, CA 94610 | Bart - "The Simpsons" UUCP: {uunet,ucbvax}!unisoft!bdt!david |
saj@chinet.chi.il.us (Stephen Jacobs) (08/20/89)
In the referenced article, David Beckemeyer repeated his offer to donate the
RTX multitasking kernel to the public domain <under the right circumstances>.
He takes us all to task because all he requires is for someone to write a
worthwhile application to go with it, and in 2 years, nobody wrote one. As
I remember the earlier discussion, though, the conditions were never so
clearcut before. I remember a lot of offers to make RTX available free if
anyone could give him a good reason, and then a general fading out of
discussion. So: somebody does a printer daemon or a shell with job control
and then we can all have RTX? That's a more concrete target.
Steve J.