S.Usher@ucl-cs.UUCP (08/09/89)
From: Stephen Usher <S.Usher@uk.ac.ucl.cs>
I can see one or two major problems with TOS if you try to make it
multi-task. The biggest problem is the file system. What happens when two
tasks want to access the same file at the same time? What error message do
you return? TOS cannot handle such things and there are no error returns
which mean "in use". Working out which process gets access is difficult,
it's fine if both the processes want to read (you give both shared access,
again not possible with TOS), but what if one wants to write?
Another problem (though it should be under the same heading) is device
access. This MUST be exclusive, after all you don't want two programs trying
to write to the printer at once.
Fixing the above would also allow for true networking possibilities, after
all, if you can have two processes accessing resources at the same time, why
not two machines?
This brings me to my next point.
If the ST could multitask, then a true network system could be built VERY
simply using a server task on each machine sitting on the network (it could
use the MIDI port to start with). In this way there would not have to be ANY
fileserver machine and ALL resources could be shared.
All of the above can be done on a Sinclair QL, even the networking! I know
what I'm talking about, Multitasking is great, I REALLY miss it on the ST,
so much so that I prefer the QL for doing assembler program developement for
the ST!
Stephen Usher
Addresses:-
(JANET)
S.Usher@uk.ac.ucl.cs or UCACMSU@uk.ac.ucl.euclid
or ford@uk.ac.ed.cs.tardis
--8<-------------- Cut --------------------- Here -------------------------leo@philmds.UUCP (Leo de Wit) (08/11/89)
In article <359@ucl-cs.UUCP> S.Usher@ucl-cs.UUCP writes: |From: Stephen Usher <S.Usher@uk.ac.ucl.cs> | | |I can see one or two major problems with TOS if you try to make it |multi-task. The biggest problem is the file system. What happens when two |tasks want to access the same file at the same time? What error message do |you return? TOS cannot handle such things and there are no error returns |which mean "in use". Working out which process gets access is difficult, |it's fine if both the processes want to read (you give both shared access, |again not possible with TOS), but what if one wants to write? This problem is already there with the current (not multi-tasking) TOS. Write a 'more'-like utility for the ST and you'll find out: The more program opens the file for read. Now if you type 'v', you Pexec() a vi program which will write out a file on exit. If you now exit more: Surprise! two files with the same name :-(. The remark about shared (read) access not being possible with TOS I'll not take seriously, 'cause that just isn't true (the more/vi combination is just an example of this. Generally, a Pexec'ed child also inherits its parent's open files). | |Another problem (though it should be under the same heading) is device |access. This MUST be exclusive, after all you don't want two programs trying |to write to the printer at once. The question is, whether you want exclusive device access. For instance, in Unix, when you leave the printer device writable for everyone (e.g. in a small system), two programs can write to the printer at once (or to the terminal, for that matter). No, device access must not always be exclusive, though in the cases when it must be it would require some work for instance to make printer access exclusive in the current TOS (e.g. like in Unix by a lpd daemon). [] |If the ST could multitask, then a true network system could be built VERY |simply using a server task on each machine sitting on the network (it could |use the MIDI port to start with). In this way there would not have to be ANY |fileserver machine and ALL resources could be shared. | |All of the above can be done on a Sinclair QL, even the networking! I know |what I'm talking about, Multitasking is great, I REALLY miss it on the ST, |so much so that I prefer the QL for doing assembler program developement for |the ST! But now the question arises: what do you use your ST for? Leo.
Z4648252@SFAUSTIN.BITNET (Z4648252) (08/18/89)
Steven Usher writes: >I can see one or two major problems with TOS if you try to make >it multitask. The biggest problem is the file system. What >happens when two tasks want to access the same file at the same >time? What error message do you return? TOS cannot handle such >things and there are no error returns which mean "in use". Don't ever say NEVER or CANNOT. Just doesn't work when dealing with computers. Tim Purves' BBS versions 2.0 and up can and do work well when the same file is accessed by two tasks on an ST. While a user is logged onto the ST, accessing a file (downloading), another user, or even the SysOp can access or download the same file. No crashes, no bombers. It just works. Larry Rymal in East Texas <Z4648252@SFAUSTIN.BITNET>
ralph@cc.brunel.ac.uk (Ralph Mitchell) (08/31/89)
In article <890817.22101246.016913@SFA.CP6> Z4648252@SFAUSTIN.BITNET (Z4648252) writes: >Steven Usher writes: > >>I can see one or two major problems with TOS if you try to make >>it multitask. The biggest problem is the file system. What >>happens when two tasks want to access the same file at the same >>time? What error message do you return? TOS cannot handle such >>things and there are no error returns which mean "in use". > > Don't ever say NEVER or CANNOT. Just doesn't work when dealing >with computers. Tim Purves' BBS versions 2.0 and up can and do >work well when the same file is accessed by two tasks on an ST. > While a user is logged onto the ST, accessing a file (downloading), >another user, or even the SysOp can access or download the same file. >No crashes, no bombers. It just works. On the other hand, that's not necessarily TOS handling multi-user access. The BBS program can implement file/record locking within itself, because the users interact with the BBS, not with TOS. Simple subroutines can be used for open/close with a linked list of filenames stored for access control. Each entry could have flags allowing one writer or multiple readers. The flags fields could also contain elements for recording the id of each user that has the file open, in case the sysop needs to remove or replace the file. Then if you have special subroutines for read/write, you can even have record locking and caching. All this, and TOS only sees single user access because the BBS is the user... Ralph Mitchell -- JANET: ralph@uk.ac.brunel.cc ARPA: ralph%cc.brunel.ac.uk@cwi.nl UUCP: ...ukc!cc.brunel!ralph PHONE: +44 895 74000 x2561 "There's so many different worlds, so many different Suns" - Dire Straits "Never underestimate the power of human stupidity" - Salvor Hardin, Foundation