glee@cognos.uucp (Godfrey Lee) (09/17/87)
Well, the odd vote still trickles in, but here is the result so far: "Do you want Commodore to add resource tracking into the next release of the operating system, even to the exclusion of something else?" ------------------------------------------------------------------------- Strong "yes", as categorized by the presence of "!", such as "YES!!!": 11 "Yes": 7 Qualified "yes", "depends on what else gets excluded": 1 Other, such as "no": 0 ------------------------------------------------------------------------- So I guess it is unanimous. Commodore, put resource tracking into 1.3, pretty please? -- Godfrey Lee P.O. Box 9707 Cognos Incorporated 3755 Riverside Dr. VOICE: (613) 738-1440 FAX: (613) 738-0002 Ottawa, Ontario UUCP: decvax!utzoo!dciem!nrcaer!cognos!glee CANADA K1G 3Z4
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (09/22/87)
In article <1449@tao.UUCP> glee@cognos.uucp (Godfrey Lee) writes: >Well, the odd vote still trickles in, but here is the result so far: > "Do you want Commodore to add resource tracking into the next release of > the operating system, even to the exclusion of something else?" >------------------------------------------------------------------------- > Strong "yes", as categorized by the presence of "!", such as "YES!!!": > 11 > "Yes": > 7 > Qualified "yes", "depends on what else gets excluded": > 1 > Other, such as "no": > 0 >------------------------------------------------------------------------- >So I guess it is unanimous. > No, it isn't. I tried mailing you a "no", but the mailer bounced it. My response to the question, as phrased, is no. Why? Because I can see no way to integrate robust resource tracking into the current OS architecture without causing MAXINT headaches, as well as breaking nearly everything in sight. Now then, I said, "as phrased." What that means is that, yes, I'd like to have resource tracking. But not at the expense of breaking everything else. What I would like to see is a *totally new* kickstart (2.0?). I want this Kickstart to have resource tracking, as well as a DOS free of BPTR's, with a real fork() (or at least vfork()) call, OS support for an MMU whether it's present or not, and a few other goodies. Naturally, this would represent a major software change for everyone. This actually can be viewed as an advantage, since all developers will be aware that all the rules have changed. When the new OS becomes available, developer's products will take full advantage of them, and there won't be any of this "lame duck" code hanging around in the OS ROMs. Of course, the probability of this actually happening is only slightly higher than winning the Publisher's Clearing House Giveaway. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Bike shrunk by popular demand, dual ---> !{well,unicom}!ewhac O----^o But it's still the only way to fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
perry@atux01.UUCP (09/22/87)
Resource tracking on the Amiga is a bogus concession to bogus programmers. The Amiga is the way it is. Learn to live with it. Adding resource track- ing would be a major hack and slash job and certainly never produce any thing any good (or backwardly compatible). A much more effective proposal would be along the lines of what Chuck (mcmannis) suggested. A standard set of Remote Control Message primitives. This has the benefit of being implemented completely outside the operating system which means all code will continue to work with or with out this facility. This remote control capability is trivial to implement, I've done it in FaccII. Forget this resource tracking nonsense. Let's get on with some- thing more feasible, more flexible, and certainly more elegant instead of trying to wedge all sorts of crap into the o.s. to help lazy programmers. (Chuck, I will participate in a Remote Control Standards Committee, call me to arrange it (201) 563-0529)) Perry Kivolowitz - ASDG Incorporated - (201) 563-0529
peter@sugar.UUCP (Peter da Silva) (09/25/87)
> [we need a standard message port for doing things like... and killing > programs] Yes, we need a standard message port that programs look at. What are our choices? Well, IDCMP is out, 'cos not all programs open windows. And of course Intuition doesn't like you IDCMPing behins its back. How about agreeing to use the task message port? All programs already have one of these? If not, why not? BUT... don't expect this message port to solve the "killing wedged program" problem. Wedged programs are usually wedged because they're in an infinite loop somewhere and not looking at their message port. A better solution is to agree to stick your cleanup routine in the entry in the task structure for this purpose. To kill a program you call this routine in the program's context. Badly behaved programs will just have the default RemTask here, but at least they won't be soaking up CPU time anymore. Well behaved ones will clean up almost everything and go away. You'll be no worse off, and maybe better off. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today? -- Disclaimer: These aren't mere opinions... these are *values*.