Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!labrea!jade!eris!mwm From: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) Newsgroups: comp.sys.amiga Subject: Re: A proposed solution to the resource tracking problem (long) Message-ID: <5043@jade.BERKELEY.EDU> Date: Wed, 9-Sep-87 20:08:45 EDT Article-I.D.: jade.5043 Posted: Wed Sep 9 20:08:45 1987 Date-Received: Sat, 12-Sep-87 00:38:27 EDT References: <8709091634.AA19588@cory.Berkeley.EDU> Sender: usenet@jade.BERKELEY.EDU Reply-To: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) Organization: Missionaria Phonibalonica Lines: 58 In article <8709091634.AA19588@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: < I have an idea: Make the resource tracking contingent on a new DOS. This appears to be the only solution. The problem is (as stated before) that the Amiga probably can't survive a non-compatable (or at least mostly non-compatable) upgrade at this point. Maybe a two-phase upgrade, over the course of a year or more: Phase 1) A new DOS that is backwards compatable, but supports resource tracking if you want it. This should include notes on how to make a program track resources, and warnings that the resource tracking will be mandatory in the future. Phase 2) The mandatory resource tracking version, that is *not* backwards compatable. The reason for this is that there are more nasties than you want to think about with adding the ability to kill a task. For instance, let's take a trivial example: CLIENT opens port "server.port" and sends it a message containing some text. SERVER recieves the message from CLIENT, and goes away to do things based on the text of the message. Later, the SERVER is through with the text, so it does a ReplyMsg() on the saved message. CLIENT gets the reply, frees the port & etc, and then goes about it's merry business. Now, add resource tracking and the ability to kill a task/process to this picture. Suddenly, CLIENT has to be able to deal with "He's dead, Jim" messages on the reply port, and SERVER has to be able to figure out which of the ports it's hanging onto should be thrown out when it gets a "He's dead" message on "server.port". Likewise for *any* resource that might be shared between two processes. Especially if the protocol is such that task1 allocates the resource, fills it and passes it to task2, who will free it. Basically, you need a new set of mechanisms. One for indicating which resources you do/don't want freed, whether it's shared or not (and with who), and what you want done if one of the sharers dies. Plus, of course, ways of indicating that you're picking up a shared resource, and what to do etc. Of course, I'd love to be wrong, and see a transparent way of doing resource tracking including shared resource & death of shareholders without breaking existing code. Anyone wanna try?