Path: utzoo!attcan!uunet!mcvax!hp4nl!phigate!philmds!leo
From: leo@philmds.UUCP (Leo de Wit)
Newsgroups: comp.sys.atari.st
Subject: Re: Multitasking on the ST
Message-ID: <1069@philmds.UUCP>
Date: 12 Aug 89 14:26:05 GMT
References: <8908021826.AA05333@ucbvax.Berkeley.EDU> <15627@watdragon.waterloo.edu> <1989Aug4.173233.8259@sj.ate.slb.com> <1067@philmds.UUCP> <1989Aug11.175942.6534@sj.ate.slb.com>
Reply-To: leo@philmds.UUCP (Leo de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 86

In article <1989Aug11.175942.6534@sj.ate.slb.com> greg@sj.ate.slb.com (Greg Wageman) writes:
|In article <1067@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
    [some stuff left out]
|>        If a process does a call that may involve some time, like
|>reading a character from the keyboard (Cconin(), Cnecin()), this
|>process only continues its call when there is a character available, so
|>it will not unnecessarily block other processes.
|
|Will you be trapping these interrupts so that you can potentially
|unblock tasks waiting on them?

Not quite, but to the same effect. What in fact happens, is that before
the process enters the real GEMDOS function (the handling of Cconin or
whatever) but after its context has been saved on its basepage and
stack, the system will look at what process to continue with (of course
this could just as well be the same process).  Processes that are
waiting for some state change like a character from the keyboard
becoming available, or the printer being ready to receive further data,
are marked that way and will only be selected if the state they're
waiting for changes (the test for the changed state is just a simple
index comparision in most cases). Calls that can be safely assumed to
complete within a reasonable amount of time are not marked waiting
(although one could perhaps win something by switching out a process
that wants to write to disk when the disk is not yet available).
When no waiting processes can be served (no state changes) the other
processes are searched for the least served one (processes have a
priority and a 'serviced' number).

A few problem calls remain: Cconrs(), which reads an entire line from
the keyboard. One can at best test for the first character being
available, but the user could still take indefinitely to complete his
line. Shells that do command line editing, history completion etc.
generally won't have a problem, since they typically process their
input character by character. A solution would be to rewrite Cconrs()
to be re-entrant (no problem since I recently patched Cconrs() to
handle a history mechanism, command line editing and file name
completion).

    []
|I must admit the idea sounds like it has merit.  However it's easy to
|try something like this when blissfully unaware of the pitfalls.  The
|biggest one I see is that GEMDOS itself is not written to be
|re-entrant.

Sure, but a) GEMDOS is not being re-entered and b) in a special way,
GEMDOS IS re-entrant. After these stunning remarks, I'll have to make
myself clear 8-):
Consider a series of programs that call each other by a Pexec(), for
instance a shell starts make, which starts a compiler, which ...
Note that each of them only returns from their Pexec after the Pexec'ed
program has finished. That program probably did a lot of GEMDOS calls
---> there you have your re-entrancy (in a special way). The whole trick
is that, while one process cannot re-enter GEMDOS (it would at least
trash registers left on the basepage for the restore of the previous
call), multiple processes can very well all be in a GEMDOS call
(they're not yet performing their function, only saved their state).

|You will have to be careful when you implement time-slicing that you
|do not suspend a process while it is in the midst of a GEMDOS call.
   [story about semaphores, critical sections left out]

But the time-slicing (implemented yesterday evening!) only takes effect
when the program was in user mode. This guarantees you're not
interrupting any progressing GEMDOS/(X)BIOS/GEM call. Small and
beautiful. In fact, my semaphore is the supervisor bit in the program
status word!

|There are probably thousands of such potential problems.  I don't even
|want to think about the potential for trashing the disk due to
|simultaneous updating...

If there is a problem with this scheme, the problem can be reproduced
in the current (unmodified) TOS, so it was already there.  As for
simultaneous updating, each GEMDOS call is completed before the next is
done. No trashing.

|Still, it sounds like fun to play with.

It sure is!! B.T.W. does that sound like an alpha/beta tester :-) ?

Cheers,
         Leo.

P.S. The current version screamed for job control, signalling etc. so
that's being implemented right now (together with some system calls
like signal() and kill()).