Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!texbell!sugar!peter From: peter@sugar.hackercorp.com (Peter da Silva) Newsgroups: comp.sys.amiga.tech Subject: Re: resource tracking Keywords: Discipline, discipline Message-ID: <5185@sugar.hackercorp.com> Date: 20 Feb 90 04:55:07 GMT References: <355.25C92297@weyr.FIDONET.ORG> <926@tardis.Tymnet.COM> <352@amgraf.UUCP> <5156@sugar.hackercorp.com> <5159@sugar.hackercorp.com> <9704@cbmvax.commodore.com> <5178@sugar.hackercorp.com> <22955@usc.edu> Reply-To: peter@sugar.hackercorp.com (Peter da Silva) Organization: Sugar Land Unix - Houston Lines: 48 The subject at hand is resource tracking. The question is who owns a resource. The problem is that on the Amiga ownership of a resource is a slippery thing. In article <22955@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: > Well, on the Amiga ALL system calls are done through libraries. Name me > one system call in graphics.library that is a "message". I don't think there's anything in graphics.library that's a system call. A shared library is a great thing, but it's still a shared library. It executes in the context (and the ownership) of the task currently executing. To actually do I/O, and in particular to perform input, you have to send messages around. You can use code in the libraries or you can build the packets and send the messages yourself. The result is the same... control over the ownership of the data changes. Turn to the front of your Rom Kernel Manual: Libraries and Devices. (I know you have one somewhere). Look at figure P-1. Virtually all of those little black lines are messages. Let's trace a typical system call. How about "read"? I think reading data from files is one of the top system calls. OK, you have this thing called a file handle. You can either use the code in dos.library or you can use Matt Dillon's asynchronous I/O routines or you can cut them yourselves. But what you actually *do* is send a packet to another task... the file system... asking for some data. If the file system has the data, it replies to your message. Otherwise it sends a message to another task... trackdisk.device, say... and when it gets a response sends the block back to you. And that's a simple call. How about tracing the path of a read from console.device with a couple of input handlers installed? But you know all this. In UNIX this sort of stuff is the exception. You make a read() system call, and enter kernel mode. Your process, your execution context, follows that block of data all the way down to the oxide and back. So... back to the point. On UNIX IPC is an exception. On the Amiga it's the rule. You can't have an Amiga program that doesn't do it. So resource tracking is a harder job. Which is all I said. You know all this. I know you know. You know I know this stuff as well. And I know you know. You know I know you know. And so on. So what's the problem? -- _--_|\ Peter da Silva . / \ \_.--._/ I haven't lost my mind, it's backed up on tape somewhere! v "Have you hugged your wolf today?" `-_-'