Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!jarthur!nntp-server.caltech.edu!toddpw
From: toddpw@nntp-server.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2
Subject: Re: GS/OS Close(0)
Message-ID: <1991Apr3.025718.5615@nntp-server.caltech.edu>
Date: 3 Apr 91 02:57:18 GMT
References: <51058@apple.Apple.COM>
Organization: California Institute of Technology, Pasadena
Lines: 51

dlyons@Apple.COM (David A. Lyons) writes:

>I'm missing something:  What do memory manager User IDs have to do with
>GS/OS Close(0) calls?

We want to prevent a Close(0) from closing files that the application didn't
open!!

Suppose we have some sort of multifinder environment up. An NDA or application
opens a file while another application (say APW or ORCA) is using a shell
application, and the file level is hiked up so the shell application's files
can be closed when it quits -- by a Close(0) from the controlling program.

Under the current system, with no UserID tags on open files (GS/OS should have
used UserID tags from the start; the TOOLBOX should have used UserID tags far
more extensively than it does) when that Close(0) is executed by the shell all
files opened at the current level or above get closed, INCLUDING the files
opened by the NDAs or other applications. Not good.

> If you're proposing that GS/OS associate a User ID
>with every file reference number, that's an interesting idea, but a
>"MultiFinder" could do that itself, just by intercepting Open and Close
>GS/OS calls.

True. I however think it would be MUCH cleaner if a process manager were
implemented in GS/OS itself. The alternative is to have a multifinder
that has to save and restore ALL the prefixes (blech!) when it would be better
to have GS/OS support saving and restoring the current application. The
Resource Manager does it properly, why can't GS/OS?

>The UserID system has plenty of value other than for MF-type switching;
>several parts of the *toolbox* are a much bigger barrier barrier to a
>MF than GS/OS is.

That's not obvious to me from my readings of the toolbox manual. If anything
the GS toolbox is better designed to make the move to a multi-application
environment than the Mac toolbox was. The real problem is in arbitrating
resource use between applications -- patching the tool locator to use UserID's
uniformly for keeping track of who started what is not too bad, but points out
a fundamental flaw in the toolbox itself -- the UserID is not enforced well
enough and the initial application guidelines left plenty of room for making
program switchers difficult. Programs that work with the current version of
the operating system are better equipped to deal with the changes that will
be necessary. I think it is important that the tool and O/S teams at Apple
give some serious thought to this problem -- the future is ALWAYS more
important than the past and I am willing to bet that most of the applications
people really care about will still work with a toolbox and O/S modified to
properly support multitasking. In the end, it's grow or die.

Todd Whitesel
toddpw @ tybalt.caltech.edu