[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference hydra::amiga_v1

Title:	AMIGA NOTES
Notice:	Join us in the NEW conference - HYDRA::AMIGA_V2
Moderator:	HYDRA::MOORE

Created:	Sat Apr 26 1986
Last Modified:	Wed Feb 05 1992
Last Successful Update:	Fri Jun 06 1997
Number of topics:	5378
Total number of notes:	38326

4296.0. "Resource Tracking...." by TENAYA::MWM () Tue Nov 20 1990 20:31

In 4273.15, Dave Brannon wishes that CBM would provide (among other things)
resource tracking.

This is a common wish, and almost everybody acts like it's the only reasonable
thing to do. I'm not so sure of that.

First, I don't know of any OS commonly found on personal computers prior to
the Amiga that had full resource tracking. Most jast gave your program
the system, and took it _all_ back when you finished, unless you went to great
pains to prevent that from happening (CP/M, MS-DOS, etc); some provided
partial resource tracking (OS/9).

Second, it's not a great burden to program for that kind of environment.
Learning to free everything you get from the OS (or give it to someone else
who'll free it) isn't any more of a burden than learning to ask the OS for
everything you need (of course, there are commercial products that fail to
do these things).

Finally, and here's the real point, I can't see any way to add resource
tracking without breaking the system as it now exists. More explicitly,
it breaks the free-for-all resource sharing that has existed for the last
five years.

Every OS (except AmigaDOS) that I've worked on comes into one of two
categories for sharing objects. Either only the most trivial of sharing
was allowed, or you had to bend over backwards to arrange to share objects.
That this isn't true on the Amiga is - to me, anyway - a major win.

Adding full resource tracking - and especially getting the only real benefit
of it by allowing process to be externally terminated - requires making it
possible to remove all the resources a task allocated that it expects to free
without crashing the system, even if they are currently being manipulated
by some other process. Ditto for objects that other processes are expecting
to get back from your "dead" task, or are expecting to let it manipulate. (And
hanging these processes -  which I've seen suggested - doesn't cut it. Might
as well reboot as hang the disk device or intuition) So far, that's not much
of a problem, but you also have to provide a way for tasks to indicate whether
they expect memory back.

And now, the question. How do you propose to provide the above facilities
without breaking more than some large percentage (say, 30%) of existing
applications software? If you're willing to break everything, then CBM
is already shipping a solution, hence the "don't break the world" solution.

BTW, any application that provide a full-blown ARexx interface will
expect to free memory allocated by another task, and etc.

Please - don't tell me why reesource tracking is wonderful. Tell me how you
do it without breaking the world.

	<mike

T.R	Title	User	Personal Name	Date	Lines
4296.1	break everything and do it right!	WJG::GUINEAU		`Wed Nov 21 1990 07:25`	20
	> Please - don't tell me why reesource tracking is wonderful. Tell me how you > do it without breaking the world. > > <mike Well, how about providing some kind of tag that you associate with a resource that marks it as PUBLIC or PRIVATE. PUBLIC stuff is untouched at resource collection time, PRIVATE stuff is freed. By taking PUBLIC as the default (ie state of all resources used in the past 5 years) you don't break existing programs. Of course the logistics of implementing the PUBLIC/PRIVATE tags can be a nightmare - not unlike getting virtual memory support quitely slipped in. john P.S. resource tracking can be wonderfull.
4296.2		BARD::mcafee	Steve McAfee	`Wed Nov 21 1990 10:19`	30
	I agree that we don't want to break a large percentage of the software. If someone wants resource tracking that badly they will be able to get UNIX. Some people think that partial resource tracking is useless though and I would tend to disagree. If there are some things which can be done to make the system more reliable without significantly damaging performance and compatibility, then I think would should pursue them. One interesting thing which was suggested on usenet and I believe someone from CBM liked (valentin?) was using the MMU to protect "unallocated" memory. I think this is a pretty neat idea which would catch a lot of buggy programs. I don't know if anyone ever wrote a program to do this though I guess it probably would have to be CBM. Unfortunately, without good resource tracking there isn't much you can do when someone trounces a free memory location. Providing mechanisms for new code to utilize would over time I think allow programmers to use the protected mechanisms. I haven't heard anyone say that this is NOT possible, but a number of people complain they want all or nothing. As John suggests in .1 I think we could make a gradual transition to a protected system. The drawbacks however are that programs have to explicitly declare resources to be protected. On most protected systems this is not the case, but so what! Declaring removable resources explicitly is certainly no worse than the many, many hacks on the PC and MAC for doing multitasking. We've already got one up on those machines and they are leapfrogging over us with hardware solutions (80486, etc). Sorry for the long-windedness... -steve
4296.3	Part of that is on the way...	TENAYA::MWM		`Wed Nov 21 1990 13:59`	42
	Re .1 - Well, there's the much-ignored MEMF_PUBLIC flag on memory allocations. Trouble is, almost nobody uses it, and the system doesn't enforce it, so even those who _try_ to use it don't know if they managed to get all the bugs out. Of course, it was never explicitly documented as to what is/isn't required to be tagged as public (e.g. - disk IO buffers?), so even if you got them all "right", you may not have them right according to the system. CBM has added a new flag - MEMF_VIRTUAL - but they aren't saying what its for. Also, this only solves 1/2 the problems resource tracking lets you deal with - protection. The other (and more important, in my view) is being able to terminate a task and reclaim it's resources without it's cooperation. Re .2 - Resource tracking and protection are different, but related, things. CBM has already made several tools available to developers that reports when you write or read from memory that's not yours. Right now, all it does is spew text out one of the hardware ports (serial or parallel). A version that used the 2.0 software error requester (i.e. - suspend the process, or reboot) would be reasonable to give to users. It would also mean you could catch programs _before_ they trashed large parts of your system. Going to a fully protected system (one where each task can only manipulate that which belongs to it) has the same kinds of problems as doing full resource tracking - you have to break sharing. I personally feel that a mostly protected system (by default, you can't write on code, or touch memory not allocated by some task) would be a major win, and would _not_ break anything. Resource tracking, on the other hand, doesn't have a partial state. Either the system correctly knows what is your process is "owns", or it doesn't. Full protection requires resource tracking, but not vice versa. Getting resource tracking means you have to deal with resource sharing. While resource tracking is great, so is unresticted sharing. I want to know if you can get both, or at least a reasonable facsimile of the latter with the former. <mike
4296.4		TLE::RMEYERS	Randy Meyers	`Wed Nov 21 1990 14:05`	34
	Re: .0 >Finally, and here's the real point, I can't see any way to add resource >tracking without breaking the system as it now exists. More explicitly, >it breaks the free-for-all resource sharing that has existed for the last >five years. I agree that it would be a disaster to make the current AmigaDOS system calls do resource tracking. However, I don't see any reason not to add a whole new set of functions to do resource tracking: If you call OpenScreen() you get a non-tracked screen. If you call RTOpenScreen(), you get a screen that is closed by the system if your task dies. An observation: it isn't that there is no resource tracking on the Amiga; it's just that all of the resource tracking is ad hoc. All of the well written Amiga programs have their own method of doing resource tracking. Popular methods are: use the standard C library, use the ARP library, write your own exit() function, track everything with if statements. The only thing that needs doing is to standardize how resource tracking is done (so the system can deallocate the resources if the program doesn't) and to hide the tracking so that programmers don't have to worry with it. For example, back in the days before the Lattice C debugger, I used Metascope to debug my programs. If I stepped the program to the bug and wanted the program to terminate early, I would just edit the PC to point at exit() and continue the program. Exit() closed all of the files and released memory, and I had a clean abort of the task. When I was doing a lot of AmigaDOS magic, I could pull the same trick by calling my cleanup routine that closed the windows, screens, and libraries before calling exit(). There would be a lot of mileage in adding a longword to the Exec task structure for a task abort function...