🚀 go-pugleaf

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