coatta@grads.cs.ubc.ca (Terry Coatta) (12/29/88)
Jim Mackraz writes: >PS: And in case you haven't heard, programs using the private part >of IntuitionBase will neither compile nor work under V1.4. Sympathy >in this area will be very hard to get out from me. I certainly hope that WB 1.4 has a vscreen-like capability in that case. If you take away my vscreen I think I deserve a little sympathy! Terry Coatta Dept. of Computer Science, UBC, Vancouver BC, Canada coatta@grads.cs.ubc.cdn `What I lack in intelligence, I more than compensate for with stupidity'
john13@garfield.MUN.EDU (John Russell) (01/06/89)
In article <277@ubc-cs.UUCP> coatta@grads.cs.ubc.ca (Terry Coatta) writes: ]Jim Mackraz writes: ] ]>PS: And in case you haven't heard, programs using the private part ]>of IntuitionBase will neither compile nor work under V1.4. Sympathy ]>in this area will be very hard to get out from me. I hope that when you take away access to structure parts that users may arguably have a need to get at, a method is provided for getting at them legally. For instance, a game like FirePower which sometimes messes with the MouseLimits, needs a legitimate way to tinker with them. If IntuitionBase no longer has the old fields for them, I hope there are calls like Get/SetMouseLimits so that new versions of such programs can be released. (Perhaps some fields like this will migrate into the Screen structure?) John -- "If you steal all money, kids not be able to BUY TOYS!" -- Saturday morning cartoon character explaining why theft is bad
jimm@amiga.UUCP (Jim Mackraz) (01/08/89)
In article <5062@garfield.MUN.EDU> john13@garfield.UUCP (John Russell) writes: )]Jim Mackraz writes: )] )]>PS: And in case you haven't heard, programs using the private part )]>of IntuitionBase will neither compile nor work under V1.4. Sympathy )]>in this area will be very hard to get out from me. ) )I hope that when you take away access to structure parts that users may )arguably have a need to get at, a method is provided for getting at them )legally. ) )For instance, a game like FirePower which sometimes messes with the )MouseLimits, needs a legitimate way to tinker with them. If IntuitionBase )no longer has the old fields for them, I hope there are calls like )Get/SetMouseLimits so that new versions of such programs can be released. )(Perhaps some fields like this will migrate into the Screen structure?) ) )John In general, we'll try to be receptive to the feedback from our certified developers during the alpha and beta phases on such things. FirePower doesn't use the mouse or the pointer, so I'm a little confused about that. Some of my favorite programs, such as Dale's Incredible Fifteen-Color Pointer hack, will cease to work. We'll try to provide what you need to do the job. Mouse limits, in particular, are very tricky right now and getting trickier. I don't anticipate adding programmer control of them for V1.4, although the major reason for screwing with them was overscan which we intend to support fully. Please don't confuse this reasonable and receptive position of mine with sympathy for IBase hackers. ;^) jimm -- Jim Mackraz, I and I Computing "Like you said when we crawled down {cbmvax,well,oliveb}!amiga!jimm from the trees: We're in transition." - Gang of Four Opinions are my own. Comments are not to be taken as Commodore official policy.
rap@ardent.UUCP (Rob Peck) (01/10/89)
In article <5062@garfield.MUN.EDU>, john13@garfield.MUN.EDU (John Russell) writes: > In article <277@ubc-cs.UUCP> coatta@grads.cs.ubc.ca (Terry Coatta) writes: > ]Jim Mackraz writes: > ] > ]>PS: And in case you haven't heard, programs using the private part > ]>of IntuitionBase will neither compile nor work under V1.4. Sympathy > ]>in this area will be very hard to get out from me. I was just thinking the other day about the A2500, MMU's and Unix interfacing to AmigaDOS/Intuition... I realize that much of the Amiga system passes pointers back and forth (messages and message ports are used extensively for I/O among other things). And many (make that many many many) structures include pointers to other things that they'd use. I was just curious as to whether there is a movement afoot for 1.4 (or would it of necessity be 2.0) to provide intermediary support for proper intertask communications without the MMU "getting in the way". In other words, a library that provides, among other things, registering a new task with a resource manager, full resource tracking for that new task, creation and management of what we might have normally considered directly modifiable data structures and functions that would manipulate those structures for us. In other words, if there would be a master task, whose MMU entries managed all of CHIP RAM, such functions would become a necessity and perhaps a new VIRTUAL version of the sharable libraries would need to be created. I do realize that this does add overhead, such as message copying (unless explicitly using SHARED RAM) but that may be the price one has to pay for beginning to use an MMU. Again, just a curiosity on my part -- is this part of the plans for 1.4, or am I just dreamin'? Rob Peck
cg@myrias.UUCP (Chris Gray) (01/11/89)
The whole area of virtual memory and MMU's with respect to AmigaDOS and Exec,
etc. has been hashed over quite a bit, but Rob Peck's recent posting on it
got me thinking again. Here's another two bits worth:
Have a task for the kernel. It maps all of real memory linearly.
For a user task, map memory linearly, but only those parts that belong to
that task. Have a large part of the system available as execute only. Try to
execute as much of the system calls (library calls, device calls, etc.) as
possible under the map of the user task.
This scheme provides protection, but no true virtual memory. For many
purposes (not UNIX, unfortunately) that would be fine.
If a system is to be secure, it has to check system call parameters before it
blindly goes using them, or it must use them only under the memory map of
the owning task. The former (checking) can be quite expensive for some of
the Amiga's library calls, so we want as much as possible to be done using
the latter. To do this, we want the bulk of the library and system code
available in the user task address space, so that calls can be direct (i.e.
we don't "go through the gate" until as late as possible, and until as much
as possible has been checked by just using it within the user task's map).
There are a lot of problems here (such as where to draw all the lines), but
if we have to programmatically check all parameters to all library calls,
etc., then the poor Amiga isn't going to run very fast. Those checks would
also add a lot to the bulk of AmigaDOS, and would need a lot of work to
implement correctly.
Any structure allocated by a system call should, if possible, be in system
space and only readable to the user task. For example, when opening a window,
the returned window structure should only be readable by the caller, but
read-writeable by the system. The same goes for everything that the
window structure points at (this requires system library routines to create
all of the structures, like gadgets, menus, etc. that are now owned by the
user task, so that they can be owned by the system). This puts some crimps
into the styles of those who like to roll their own (like me, when I move
a narrow screen into the middle by pokeing the dyOffset in the ViewPort!),
but some provisions could be made by adding more library calls, which could
check things once, on setup, rather than on each using call.
So, how far off the wall am I this time?
--
Chris Gray Myrias Research, Edmonton +1 403 428 1616
{uunet!mnetor,ubc-vision,watmath,vax135}!alberta!myrias!cgrap@ardent.UUCP (Rob Peck) (01/12/89)
As a followup to Chris Gray's message, what I was thinking of was something that would work with an MMU without much hassle. In essence, I was thinking of an interface library that would for example contain functions such as: RegisterMeWithSystem(); /* passes my task id in for resource track */ NWindowID = AllocateStandardWindow(); ModifyWindowParm(WindowID, parmValue); WindowID = OpenMyWindow(NWindowID); /* using the window here */ cleanup: CloseMyWindow(WindowID); DumpWindowStructure(WindowID); alternate_cleanup: UnregisterMe(); /* system closes all my windows and deallocates * anything I got ID's for from kernel process */ [by this method, trying to avoid passing pointers to MMU-protected task- local memory] WindowID is an integer you get back from the kernel function that is actually doing the resource tracking and AllocateStandardWindow gives you a NewWindow structure, but managed by the system, not by the program. Then almost all of the interface functions shown in the sample become some form of message passed to the task that actually owns the chip memory. Though there is the overhead of the call, there may not be quite as much need to copy entire data structures through some commonly accessible memory system. Each message passed to the kernel process includes the taskid (from FindTask(0)) so the kernel knows who is doing the asking and can track resources if appropriate. Too much overhead?.. maybe. I have not thought this out very thoroughly, and have not been exposed too much to other OS's that might use a similar method. Just thought I'd output a bit more of the thinking that prompted my original posting. Rob Peck
thomas@cbmvax.UUCP (Dave Thomas QA) (01/13/89)
In article <1656@ardent.UUCP> rap@ardent.UUCP (Rob Peck) writes: > As a followup to Chris Gray's message, what I was thinking of was something > that would work with an MMU without much hassle. In essence, I was thinking > of an interface library that would for example contain functions such as: > > RegisterMeWithSystem(); /* passes my task id in for resource track */ > NWindowID = AllocateStandardWindow(); > ModifyWindowParm(WindowID, parmValue); > WindowID = OpenMyWindow(NWindowID); > /* using the window here */ > cleanup: > CloseMyWindow(WindowID); > DumpWindowStructure(WindowID); > > alternate_cleanup: > UnregisterMe(); /* system closes all my windows and deallocates > * anything I got ID's for from kernel process > */ > > [by this method, trying to avoid passing pointers to MMU-protected task- > local memory] > > WindowID is an integer you get back from the kernel function that > is actually doing the resource tracking and AllocateStandardWindow gives > you a NewWindow structure, but managed by the system, not by the program. > Then almost all of the interface functions shown in the sample become > some form of message passed to the task that actually owns the chip memory. > Though there is the overhead of the call, there may not be quite as much > need to copy entire data structures through some commonly accessible > memory system. Each message passed to the kernel process includes > the taskid (from FindTask(0)) so the kernel knows who is doing the asking > and can track resources if appropriate. Too much overhead?.. maybe. > I'm not sure whether resource tracking would involve too much overhead. My gut feeling is that it could be handled without too much performance penalty. I'm not so sure that I like the idea of using descriptors instead of pointers. This would certainly break existing programs and while that could be handled by adding things like "mmu_intuition.library" while also keeping "intuition.library" it would cause all sorts of message passing problems. Probably the simplest way to use the mmu is to start making things like MEMF_PUBLIC mean something and let each task share one large 32 bit address space (instead of giving each task its own 32 bit address space). I know that MEMF_PUBLIC alone won't solve the problem, but perhaps a new class of memory attributes... > I have not thought this out very thoroughly, and have not been exposed > too much to other OS's that might use a similar method. Just thought > I'd output a bit more of the thinking that prompted my original posting. > > Rob Peck I haven't thought through all the consequences either. It seems that the OS will probably take incremental steps toward virtual memory. First memory protection, then virtual memory. Anyway, it's an interesting subject to talk about... Dave Thomas -- ============================================================================= Dave Thomas COMMODORE AMIGA TEST ENGINEERING // /_ |\/||/_ /_ UUCP ...{allegra,rutgers}!cbmvax!thomas \X/ / \| ||\// \ PHONE 215-431-9328 ============================================================================= Opinions expressed are my own...no one else wants them =============================================================================
elg@killer.DALLAS.TX.US (Eric Green) (01/14/89)
I tend to agree with Matt on this one. What everybody is clamoring for
is NOT a seperate address space for each and every process. Instead,
they just don't want other folk's processes to whomp on their own
process. What folks are asking for is memory PROTECTION, which does
not necessarily imply seperate address spaces.
Currently, AmigaDOS assumes a single linear address space. It's a
very efficient way to organize things, for a real-time system. To pass
messages around, just load the address into a register, and make a
system call, just like you do right now. And when you do a
task-switch, no TLB's or caches to flush, everything stays the same.
So you don't have LONG waits while things are flushed to disk at task
switch (remember, personal computers usually don't have super-fast
16ms ESDI drives hanging off of them). I hear that running a Sun 3
with a slow SCSI drive is positively painful. I'd hate to see the
Amiga reduced to the same level.
The ideal scheme for memory protection would be for each block of
memory to have an associated process ID, and if the writing process
isn't the same process (or a "System" process), barf (technical MIT
term for "Bad ARgument Function" -- see MACLisp sources). There was
once, a long time ago, a MMU chip for the original 68000 which did
something of the sort (though I don't know if it was ever produced).
Unfortunately, I doubt that the Unix-oriented MMU in the 68030 could
do it that way -- you'd have to chase down the list of pages currently
in memory, setting the write protects appropriately. This is probably
prohibitively inefficient. If you have 8mb of RAM, and, say, 2K pages,
that's 4,000 structures you have to chase down, probably around 20
instructions in the loop... 80,000 instructions total, a sizable
percentage of the CPU's time, and totally unacceptable for a real-time
system). If CBM ever wants to go to a real-time protected-mode
AmigaDOS, I suspect they'll have to "roll their own" MMU, unless the
68030's is more capable than I seem to recall.
Now, the other thing that people would like is resource tracking. For
some reason they seem to confuse that with having a protected-mode OS.
I fail to see the connection -- all that a MMU adds is an easy method
of memory tracking. The OS will still have to keep track of which
process owns which FileHandle/Lock, RastPort, etc., even if there IS a
MMU.
--
Eric Lee Green ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg
Snail Mail P.O. Box 92191 Lafayette, LA 70509
Netter A: In Hell they run VMS.
Netter B: No. In Hell, they run MS-DOS. And you only get 256k.sparks@corpane.UUCP (John Sparks) (01/15/89)
What I would really like to see in wb1.4 or 1.5 is a decent voice for the
Amy. The synthetic voice Amy has now sux. it sounds like a cross
between Arnold Swarzenegger and the Muppets Swedish Chef! The 'female'
voice is even worse! It sounds like a transvestite swedish chef.
The Amiga has enough potential power to have a really nice synthesized
voice. There is even a public domain replacement for the voice called
better-voice (I think thats the name). The person who wrote it took
digital samples of his voice to make the phonemes. It needs a lot of
work tho, the phonemes weren't recorded very well.
Why doesn't Commodore-Amiga use this approach? It would yield a much
more natural sounding voice. If they digitized a female voice for the
phoneme base, you could tune it down in pitch to a male voice, better
than you could tune up a male voice into a female one.
When ever I show off my Amiga to my friends, and I show them how I can
'make it talk', They always say:
"Oh Wow. That's neat.. er... what did it say?"
The Amy should be able to be as good as say, DECTALK, with a little
bit of work.
_______________________________________________________________________________
John Sparks // Amiga | corpane : sparks@corpane
a.k.a \X/ UUCP | blitter : john@blitter (preferred; path below)
RedHawk | {rutgers|uunet}!ukma!corpane!disk!blitter!john
(Realm's 1st Astronaut) | >> call D.I.S.K. @ 502/968-5401 thru -5406 <<
Ye Quote:
Mixed Emotions: When you see your mother-in-law back over a cliff in your
new Mecedes Benz.
_______________________________________________________________________________me128-aw@kepler.Berkeley.EDU (me128 student) (01/15/89)
In article <156@corpane.UUCP> sparks@corpane.UUCP (John Sparks) writes: > >What I would really like to see in wb1.4 or 1.5 is a decent voice for the >Amy. The synthetic voice Amy has now sux. it sounds like a cross >between Arnold Swarzenegger and the Muppets Swedish Chef! The 'female' >voice is even worse! It sounds like a transvestite swedish chef. > From what I understand, such a device was already written, but excluded from the kickstart for two reasons. 1) It was too big. The ROM is full already. 2) It was too CPU intensive. If you notice, the narrator already chokes when you have a hires 4-plane screen in front. If you ask me, I'd like it in anyway, perhaps as a disk-based library. We'll see. -Vince Lee
FelineGrace@cup.portal.com (Dana B Bourgeois) (01/16/89)
This seems like the right place to ask this question: Does anyone use the AllocRemember() and FreeRemember() calls documented in the Addison-Wesley 'Intuition Reference Manual', pp 211-214? If not, why not? The reason I ask is that I have seen comments on UseNet and in magazine articles that say AmigaDOS does not have any resource tracking and that lack is a big problem. Perhaps those calls don't work or perhaps they don't solve the problem that needs to be solved. I'd like to know. Dana "I give up on elaborate signatures"
rap@ardent.UUCP (Rob Peck) (01/17/89)
In article <27542@ucbvax.BERKELEY.EDU>, me128-aw@kepler.Berkeley.EDU (me128 student) writes: > In article <156@corpane.UUCP> sparks@corpane.UUCP (John Sparks) writes: > > > >What I would really like to see in wb1.4 or 1.5 is a decent voice for the > >Amy. The synthetic voice Amy has now sux. it sounds like a cross > >between Arnold Swarzenegger and the Muppets Swedish Chef! The 'female' > >voice is even worse! It sounds like a transvestite swedish chef. I tried out the Smooth Talker from EA, and indeed the voice is considerably better sounding. As I recall what IT still had as a potential defect was its inter-phoneme connection (talked with something of a click so to speak), [aarrgghh! - even when being serious, the puns creep in ^^^^^^^^^^^] and similar problems (used the same translator.library????) as the built-in speaker. I have not checked how much memory the smooth talker takes and have no memory whatsoever about its memory-time-hogging capabilities. (just borrowed it for a short time from a friend... guess I may have to go out and BUY a copy, because I AM still interested... have a speech interface project going on back burner now and then.) Rob Peck
w-colinp@microsoft.UUCP (Colin Plumb) (01/17/89)
FelineGrace@cup.portal.com (Dana B Bourgeois) wrote: > Does anyone use the AllocRemember() and FreeRemember() calls documented in the > Addison-Wesley 'Intuition Reference Manual', pp 211-214? If not, why not? > > The reason I ask is that I have seen comments on UseNet and in magazine > articles that say AmigaDOS does not have any resource tracking and that lack > is a big problem. Perhaps those calls don't work or perhaps they don't solve > the problem that needs to be solved. I'd like to know. They only work for memory. This is good, but: - They don't register the memory with the OS, so you can't use them to kill a task without defining some other protocol to allow an external task to find the memory lists, and - There are many other things (devices, libraries, resources, IDCMPs, etc.) that a process can have a lock on, and these aren't registered. So, all they really are is a convenience to the programmer, to make it easier to clean up. They don't do full resource tracking. -- -Colin
sterling@cbmvax.UUCP (Rick Sterling QA) (01/17/89)
In article <13592@cup.portal.com> FelineGrace@cup.portal.com (Dana B Bourgeois) writes: > This seems like the right place to ask this question: > > Does anyone use the AllocRemember() and FreeRemember() calls documented in the > Addison-Wesley 'Intuition Reference Manual', pp 211-214? If not, why not? > > The reason I ask is that I have seen comments on UseNet and in magazine > articles that say AmigaDOS does not have any resource tracking and that lack > is a big problem. Perhaps those calls don't work or perhaps they don't solve > the problem that needs to be solved. I'd like to know. > > Dana "I give up on elaborate signatures" I use these calls quite extensively in test software here at CBM and they work quite well, thankyou ;-) Resource tracking involves quite a bit more work than these memory allocation /deallocation routines can provide. - Rick - -- ============================================================================= Rick Sterling COMMODORE AMIGA TEST ENGINEERING N2CGI UUCP {allegra,rutgers}!cbmvax!sterling =============================================================================
rminnich@super.ORG (Ronald G Minnich) (01/18/89)
In article <13592@cup.portal.com> FelineGrace@cup.portal.com (Dana B Bourgeois) writes: >Does anyone use the AllocRemember() and FreeRemember() calls documented in the >Addison-Wesley 'Intuition Reference Manual', pp 211-214? If not, why not? In 1986, under lattice 3.03, i admired their clever design and used them all the time. They are neat. In fact a #defined malloc to be an AllocRemember. When LC 4.0 came along, it appeared that their malloc called AllocRemember, and so i stopped #defining things. When Arp came along i started using ArpAlloc. AllocRemember and friends are useful if your storage consists of many heaps, as that is essentially what they buy you (i.e. mark/restore but on a heap of your choice). But generally i think most people allocate and free discrete things, and for this they are less useful. ron
cmcmanis%pepper@Sun.COM (Chuck McManis) (01/18/89)
In article <13592@cup.portal.com> (Dana B Bourgeois) writes: >Does anyone use the AllocRemember() and FreeRemember() calls documented in the >Addison-Wesley 'Intuition Reference Manual', pp 211-214? If not, why not? I use them, when they are useful. They have two big drawbacks which are sort of related. One you can't "mark" the list and then free back to the last mark. This is useful when half way through a routine your request for memory fails and you would like to unwind and recover. The second is you can't "join" lists. So if you use a separate variable during a subroutine (faking a mark) then when you are ready to return you can't say JoinRemember(ptr1, ptr2); to put everything on one list. >The reason I ask is that I have seen comments on UseNet and in magazine >articles that say AmigaDOS does not have any resource tracking and that lack >is a big problem. Perhaps those calls don't work or perhaps they don't solve >the problem that needs to be solved. I'd like to know. They don't solve the problem. When you force a task to exit via an external force in say TOPS-20, all of the resources it has allocated are freed automatically. On the Amiga those are not freed and are "lost" until the next reboot. There is a big religious debate about why you can or cannot do this (it has to do with what do you trust when a program on an unprotected memory machine goes south?) and generally I don't believe we'll see it until the OS can be sure that no one has stomped on it's lists. On a side note, there has been much talk about what to use the MMU on the A2620 for. Personally, I'd like to see a version of ADOS that kept all of it's lists (like memory, tasks, etc) under lock and key. Only making memory "writable" when it is allocated via AllocMem() or some such. That way you would turn a lot of GURU crashes that corrupt location 4 or the free memory list, into simple task held's because the task tried to write outside it's legal memory space. Then a new reboot ("hot reboot") that would just clear out the user tasks and such and put you back into the "boot" state nearly instantly. In either event, I want to see a version of CARD: that uses the MMU to protect itself. No more worries about losing it due to an errant task. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
baer@percival.UUCP (Ken Baer) (01/19/89)
>In article <13592@cup.portal.com> FelineGrace@cup.portal.com (Dana B Bourgeois) writes: >> Does anyone use the AllocRemember() and FreeRemember() calls documented in the >> Addison-Wesley 'Intuition Reference Manual', pp 211-214? If not, why not? Yes, we use AllocRemember() all the time. It's especially useful when allocating/deallocating bitmaps. We even replaced all the RemAlloc() calls in the IFF functions with AllocRemember(). The drawback is you have to keep track of all your keys, which can get messy if you're not careful. -- -Ken Baer. // Hash Enterprises: When the Going gets Wierd, the Wierd go Professional \X/ USENET - baer@percival.UUCP, PLINK - KEN BAER, BIX - kbaer, "while (AINTGOTNOSATISFACTION) { do stuff }" - RJ Mical
FelineGrace@cup.portal.com (Dana B Bourgeois) (01/19/89)
FelineGrace@cup.portal.com (Dana B Bourgeois) wrote: > Does anyone use the AllocRemember() and FreeRemember() calls documented in the > Addison-Wesley 'Intuition Reference Manual', pp 211-214? If not, why not? > > The reason I ask is that I have seen comments on UseNet and in magazine > articles that say AmigaDOS does not have any resource tracking and that lack > is a big problem. Perhaps those calls don't work or perhaps they don't solve > the problem that needs to be solved. I'd like to know. They only work for memory. This is good, but: - They don't register the memory with the OS, so you can't use them to kill a task without defining some other protocol to allow an external task to find the memory lists, and - There are many other things (devices, libraries, resources, IDCMPs, etc.) that a process can have a lock on, and these aren't registered. So, all they really are is a convenience to the programmer, to make it easier to clean up. They don't do full resource tracking. -- -Colin ############################################################################### Thanks for the answer, colin. Dana (trying out my new macro) ^ ^ o o = . = \v/-\ | | | | | /| | |/ | c c=== (all right!!) Bourgeois
FelineGrace@cup.portal.com (Dana B Bourgeois) (01/19/89)
Thanks for the answer, rick. Saving bandwidth by not including anything. Dana
FelineGrace@cup.portal.com (Dana B Bourgeois) (01/19/89)
Thanks for answering my question, Ron M. Dana (saving bandwidth by not including)
FelineGrace@cup.portal.com (Dana B Bourgeois) (01/19/89)
Thanks for answering my question, Chuck Mcmanis(hope that's spelled rite) Dana
cg@myrias.UUCP (Chris Gray) (01/21/89)
Following up on Rob Peck's ideas on resource tracking, here's some thoughts I
had the other day while walking to work (its a 25 minute walk over a big,
windy bridge).
Extend all of the standard system structures (Window, Screen, Gadget, Menu,
Message, Port, etc.) with a field to contain a unique identifier. The
identifier will not repeat until after a reboot, but also contains the
task number (so it might need to be 64 bits). This identifier is placed in
all of the structures when the system creates the structures. (Note: the
structures should be self validating, that is, given a pointer to one, the
system can very quickly verify that it is a valid pointer to such a
structure. One way to be almost certain is to have yet another added 32 bit
field which contains some fast-to-compute, but difficult to fake without
knowing what it is, function of the address of the structure. When receiving
the address of such a structure, the system can do a quick check and then
be almost sure that it is valid.) We now add a new, required, entry point
to all of the libraries (exec doesn't really need one since he is the one
that is going to do the magic). This entry point is called by exec, with the
unique identifier of a current task, when that task is going away, either by
committing suicide or by being killed by someone else. The library should
then free up all resources that the task has allocated within the library.
User-provided libraries have the same facility available to them. It will
probably be helpful to have a priority associated with a library, which
governs the order in which their "taskIsDying" functions are called. This
would, for example, allow Intuition to close down all Windows and Screens,
which would result in the ViewPort, Rasters, etc. going away, before calling
the function for the graphics library, which would also want to remove those
items. Some of the libraries wouldn't even need any extra data structures
to do the required tracking - e.g. Intuition always has all Windows and
Screens nicely tied together in lists. Some structures, such as messages,
may not "belong" to the dying task when it dies. They should stick around, and
only be freed when the current owner attempts to send them elsewhere. A new
error result would indicate "recipient has died". This is probably easier
than trying to rip all of the messages away from their current owners.
Another note: I would hope that if/when we switch to an Amiga system that
supports MMU and/or does resource tracking and/or has no BCPL stuff, that
all three happen at once. That way we only need to go through a totally
incompatible system once. I wouldn't expect to see such a system for a couple
of years. Thinking about how to do some hooks to properly integrate the
graphics, sound, input, etc. aspects of the Amiga with a hosted UNIX system
might be productive at that point, also.
--
Chris Gray Myrias Research, Edmonton +1 403 428 1616
{uunet!mnetor,ubc-vision,watmath,vax135}!alberta!myrias!cg