leblanc@eecg.toronto.edu (Marcel LeBlanc) (01/14/89)
[] I'm looking for a program like the UNIX kill that will allow me to terminate a CLI spawned task. I'm writing some simple C code with the Lattice compiler v3.10 (stop laughing, I'll get around to updating someday!). What am I supposed to do when the program is in an infinite loop? A program to kill the task running under a CLI (or that CLI too if necessary) would be very handy. I work mostly with UNIX machines, so any help would be appreciated! Thanks in advance. Marcel A. LeBlanc | University of Toronto -- Toronto, Canada leblanc@eecg.toronto.edu | also: LMS Technologies Ltd, Fredericton, NB, Canada ------------------------------------------------------------------------------- UUCP: uunet!utai!eecg!leblanc BITNET: leblanc@eecg.utoronto (may work) ARPA: leblanc%eecg.toronto.edu@relay.cs.net CDNNET: <...>.toronto.cdn
billk@pnet01.cts.com (Bill W. Kelly) (01/16/89)
Marcel A. LeBlanc was asking how to kill a task on the Amiga.
You should be able to terminate the task with a RemTask(task).
You will not, however, be able to deallocate its resources.
--
Bill W. Kelly billk@pnet01.cts.com
{nosc ucsd hplabs!hp-sdd}!crash!pnet01!billk crash!pnet01!billk@nosc.milmab@druwy.ATT.COM (Alan Bland) (01/17/89)
In article <89Jan14.134000est.2661@godzilla.eecg.toronto.edu>, leblanc@eecg.toronto.edu (Marcel LeBlanc) writes: > I'm looking for a program like the UNIX kill that will allow me to terminate > a CLI spawned task. I'm writing some simple C code with the Lattice GOMF version 2 and later includes a program called "nuke" that usually does a reasonable job of killing a task. Be aware that killing a task does not free up all the resources it was using (nuke cleans up what it can, but cannot get everything) so after a few nukes you need to reboot to reclaim those resources. -- // Alan Bland // AT&T Bell Laboratories, Denver CO // (303)-538-3510 - att!druwy!mab
sean@ms.uky.edu (Sean Casey) (01/17/89)
In article <3716@crash.cts.com> billk@pnet01.cts.com (Bill W. Kelly) writes: >You should be able to terminate the task with a RemTask(task). > >You will not, however, be able to deallocate its resources. Hmmm. Why not? Doesn't AmigaDos keep track of owned resources? Sean -- *** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet *** Who sometimes never learns. {backbone site|rutgers|uunet}!ukma!sean *** U of K, Lexington Kentucky, USA ..where Christian movies are banned. *** ``There's only TWO THINGS come out of Oklahoma...''
cmcmanis%pepper@Sun.COM (Chuck McManis) (01/17/89)
In (Marcel LeBlanc) writes: > I'm looking for a program like the UNIX kill that will allow me to terminate > a CLI spawned task. Can't do it. Lots of reasons why, the solution for Lattice 3.1 is to make sure that you code either calls "CheckAbort()" or sets up an interrupt for break signals. > I'm writing some simple C code with the Lattice compiler v3.10 (stop > laughing, I'll get around to updating someday!). What am I supposed ` > to do when the program is in an infinite loop? I'm not laughing, but you should know that the 5.0 release of Lattice includes a debugger that a) you can run your program under and have it break out when it is hung, or b) start the debugger after you code gets hung and "attach" to it, change the code that is causing it to hang and then let it finish. Your best bet is to upgrade. --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.
papa@pollux.usc.edu (Marco Papa) (01/17/89)
In article <10908@s.ms.uky.edu| sean@ms.uky.edu (Sean Casey) writes: |In article <3716@crash.cts.com| billk@pnet01.cts.com (Bill W. Kelly) writes: ||You should be able to terminate the task with a RemTask(task). ||You will not, however, be able to deallocate its resources. | |Hmmm. Why not? Doesn't AmigaDos keep track of owned resources? No, it doesn't. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (01/17/89)
[ David Letterman gets his material from these lines that you *don't* see. ]
> [A program goes into an infinite loop. How do I kill it?]
You reboot the machine. A commercial program called GOMF might be
able kill your task and recover the resources, but in general, the Amiga OS
does not have the facilities to asynchronously kill a task. Sorry.
This has been a recording. :-)
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU
\_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac
O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack")
"Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctorshimoda@infohh.rmi.de (Markus Schmidt) (01/18/89)
In article <89Jan14.134000est.2661@godzilla.eecg.toronto.edu> leblanc@eecg.toronto.edu (Marcel LeBlanc) writes: >[] > >I'm looking for a program like the UNIX kill that will allow me to terminate >a CLI spawned task. I'm writing some simple C code with the Lattice Try XOPER, it does a *fine* Job on this. Even lets you CloseScreen or CloseWindow the reminiscents of a killed task! Cu Markus
davidg@killer.DALLAS.TX.US (David Guntner) (01/18/89)
From article <14729@oberon.USC.EDU>, by papa@pollux.usc.edu (Marco Papa): |In article <10908@s.ms.uky.edu| sean@ms.uky.edu (Sean Casey) writes: ||In article <3716@crash.cts.com| billk@pnet01.cts.com (Bill W. Kelly) writes: |||You should be able to terminate the task with a RemTask(task). |||You will not, however, be able to deallocate its resources. || ||Hmmm. Why not? Doesn't AmigaDos keep track of owned resources? | |No, it doesn't. If you have GOMF, there is a "Nuke" command that comes with it, which can be used to remove any task from the system. It will also return all PUBLIC memory that the task used to the system. Any privately assigned memory, however, will still be lost. --Dave -- David Guntner UUCP: {ames, mit-eddie}!killer!davidg INET: davidg@killer.DALLAS.TX.US "..Different ship, but she's got the right name. Treat --Admiral L. McCoy her like a lady, and she'll always bring you home." "Encounter at Farpoint"
jesup@cbmvax.UUCP (Randell Jesup) (01/18/89)
In article <10908@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >In article <3716@crash.cts.com> billk@pnet01.cts.com (Bill W. Kelly) writes: >>You should be able to terminate the task with a RemTask(task). >> >>You will not, however, be able to deallocate its resources. > >Hmmm. Why not? Doesn't AmigaDos keep track of owned resources? No, not in general. It can get expensive in memory/spped to do so. Also, note that RemTask() of a running process isn't very safe, unless you know it's doing a Wait(0), or I-looping (Wait(0) is preferred). If you RemTask something that is in a library call, and has resources locked (like the layers for the workbench while writing to it), you may end up with a hung machine. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
FelineGrace@cup.portal.com (Dana B Bourgeois) (01/19/89)
Alan Bland comments on the nuke program bundled with GOMF 2+: Nuke does do the best it can which sometimes is not good enough. I've used Nuke (ver 3.0) in trying to remove a hung VT100 which was dialing and found the serial device still allocated. The symptom was VT100 would not start up until I rebooted because the "read device was not found". All other programs I have removed with nuke have been complete to the best of my knowledge. I do know that after nuking a program I figure the system is on 'borrowed' time and at the next convenient opportunity I reboot "just in case". By the way, except for mount, copy, list, protect, and resi(wshell), I use ARP 1.1 without problems. The first four are WB1.3. Dana
sean@ms.uky.edu (Sean Casey) (01/20/89)
In article <5713@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >In article <10908@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >>>You will not, however, be able to deallocate its resources. >>Hmmm. Why not? Doesn't AmigaDos keep track of owned resources? > > No, not in general. It can get expensive in memory/spped to do so. Why? Seems to me that resource allocation is an infrequently done thing. It also seems to me that resources could be tracked with bitmaps. Where is the serious speed/memory degradation? Assuming I'm right, what's the REAL reason resources aren't tracked? Sean -- *** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet *** Who sometimes never learns. {backbone site|rutgers|uunet}!ukma!sean *** U of K, Lexington Kentucky, USA ..where Christian movies are banned. *** ``There's only TWO THINGS come out of Oklahoma...''
hrc@terra.dk (Henrik Raeder Clausen) (01/20/89)
In article <89Jan14.134000est.2661@godzilla.eecg.toronto.edu>, leblanc@eecg.toronto.edu (Marcel LeBlanc) writes: > I'm looking for a program like the UNIX kill that will allow me to terminate > a CLI spawned task. I'm writing some simple C code with the Lattice (part of reply from someone else. Sorry, I'm not quite used to the net yet) >GOMF version 2 and later includes a program called "nuke" that usually >does a reasonable job of killing a task. Be aware that killing a task >does not free up all the resources it was using (nuke cleans up what it >can, but cannot get everything) so after a few nukes you need to reboot An australian disk magasine Megadisk had a command like this in issue 6, called AbortCommand. It does the job to the best possible, much like GOMF's nuke command. It'll also kill tasks that have that well-known requester (select cancel to reset/debug) up, turning the requester absolutely harmless, it does not even come to front on disk activity. Problem is, I have no written autorization to redistribute it. It does seem to be PD, and is an unpaid contribution by the author. NO word whatever on the disk itself regarding status of the contents. Also my brother has written a utility to remove dead windows, but a few problems remains: it sometimes takes the system down. I might post the source for someone to trace the problem - it's quite a handy idea. BTW, to post programs, do I post it to the group itself? Henrik Clausen, hrc@daimi.dk
martens@kayak.cis.ohio-state.edu (Jeff Martens) (01/20/89)
In article <10926@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: [ stuff deleted ] >Why? Seems to me that resource allocation is an infrequently done thing. Resource allocation is infrequently done in a language like FORTRAN which has a static view of the world and doesn't allow users to allocate and deallocate memory. In something more modern, like Modula 2, Pascal, Lisp, or C, this is no longer true. Consider linked lists, trees, etc.; to manage these sorts of structures in an application program you're continuously grabbing new memory and (hopefully) returning it to the system when you're done with it. Even if you're just running FORTRAN or BASIC, the translator is going to allocate memory dynamically. >It also seems to me that resources could be tracked with bitmaps. Where >is the serious speed/memory degradation? OK. Let's keep track of every byte of RAM in the Amiga. If we allow for 8MB of RAM, then we need an 8Mb map, which comes to a megabyte. The alternatives are to increase the granularity of our map or keep it on disk. It won't fit on a floppy, and even on a hard drive performance would be hampered. If we increase the granularity to, say, a "paragraph" (Intel's term for 16 bytes if memory serves), then 8MB is thought of as 512k paragraphs, so the bitmap can fit in 64kB. This is still a considerable amount of memory, and results in wasted space if the user doesn't use memory in 16 byte chunks. Of course, it's not necessary to worry about memory that's not actually present. Assuming memory's allocated on a word basis, though, a sixteenth of your memory's gonna be just bitmaps, and this is pretty significant. [ more stuff deleted ] -- Jeff (martens@cis.ohio-state.edu)
cmcmanis%pepper@Sun.COM (Chuck McManis) (01/21/89)
In article <10908@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) asks: Does AmigaDOS track resources ? In article <5713@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) responds: No, not in general. It can get expensive in memory/speed to do so. In article <10926@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: > Why? Seems to me that resource allocation is an infrequently done thing. > It also seems to me that resources could be tracked with bitmaps. Where > is the serious speed/memory degradation? > > Assuming I'm right, what's the REAL reason resources aren't tracked? Sean you are correct, and Randell is correct as well. Depending on your application, tracking resources may or may not be expensive and may or may not be useful. Take a spreadsheet for instance. Remembering that you have opened a screen and allocated some memory takes no time at all compared to the user who is sitting there walking through the menus to load a file. In this case resource tracking is inconsequential in terms of speed. Then consider an alien invaders game where you take over the machine. Since you are going to give back the machine by rebooting it you don't particularly care or want to deal with code that tracks resources. The philosophy behind the Amiga has traditionally been more of the latter and less of the former. However, that changes as more and more people write toolkits that *do* resource tracking. I have one where I just call ToolExit() and everything I've allocated/opened/used etc gets freed up for me. (no it isn't ready to go yet) This solves the problem for 99% of the programmers out there. I think you can expect to see something that does some resource tracking in 1.4 if not in ROM, then in the form of a library for programmers. But the question you *really* want answered is, "Why can't I kill a task and have all of it's resources freed ?" And there are two answers to that. One is "Why are you killing your task? Did it go astray?" If so, killing it and freeing a list of resources it thinks it has is a very dangerous proposition. Maybe it corrupted that list before it died and you end up freeing up the Workbench screen! Or maybe it wrote all over your filesystem handler which is now merrily corrupting your disks. Etc. Basically, you don't know so you are really in a tough spot. I prudent solution is to just guru out and reboot, if you are a gambler by nature then you'll use something like GOMF and hope it didn't do any real damage. So the real answer is why put a lot of effort into that senario when it may cause you nothing but grief. On memory protected systems where you can be sure the system is secure you will have a much better shot of doing it right. --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.
jesup@cbmvax.UUCP (Randell Jesup) (01/21/89)
In article <10926@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >Why? Seems to me that resource allocation is an infrequently done thing. >It also seems to me that resources could be tracked with bitmaps. Where >is the serious speed/memory degradation? > >Assuming I'm right, what's the REAL reason resources aren't tracked? Well, that's a big assumption to make. :-) Here are some of the reasons you're wrong: resources get passed from one process/task to another, frequently. Resources are sometimes passed permanently, sometimes temporarily. AllocMem/FreeMem are often done for small chunks, and very often. There are MANY resources, and orderings in which they must be released. The system wasn't designed for it originally (or rather the never-completed original OS did some of it (though not all). Users allocate system structures and pass them to the system, instead of vice-versa. We have very limited programmer resources. Improperly written programs will leave the system potentially munged anyways, so cleaning up after them is very risky, at best (witness GOMF - sometimes saves you, but often doesn't, or you die a short time later). I could go on, but you get the idea. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
nw@palladium.UUCP (Neil Webber) (01/22/89)
>In article <10908@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >Hmmm. Why not? Doesn't AmigaDos keep track of owned resources? and Randell Jesup (of Commodore) replies > No, not in general. It can get expensive in memory/spped to do so. I do hope this isn't Commodore's "official" position on this topic. Obviously, the resources *are* being tracked -- it's just that currently each and every program is tracking its own resources (or so you hope!) Forcing everyone to track their own: a) prevents the implementation of KILL, a clearly needed feature. b) is a fertile source of bugs c) really grosses up your code (just look at the error handling and cleanup in any RKM example). In Article <32094@tut.cis.ohio-state.edu> Jeff Martens adds: >OK. Let's keep track of every byte of RAM in the Amiga. If we allow >for 8MB of RAM, then we need an 8Mb map, which comes to a megabyte. No existing programs track their own memory allocations that way (at least, I hope not!). The OS wouldn't do it that way either. Nor would it do it in 8 or 16 byte chunks. It would do it the same way every current program is forced to do it. It won't be ANY slower. It won't take up ANY additional memory. It could, in theory, save memory since the code to manage this junk wouldn't be duplicated in every program. It would make the system more robust. People will object that the Amiga programming model sometimes requires a program to allocate resources, and pass them off to another program, and sometimes the original allocating program exits, and you don't want the resource freed. This is not at all a show stopper. It is possible to design system interfaces that provide this capability. I've done all of this for a small proprietary OS, including the bit about passing resources between tasks. It really doesn't take more memory and it really doesn't cost you execution speed. All :-) it takes is extra effort when designing and implementing the system. Maybe you don't have the time for that, so you ditch resource tracking to get the product out sooner. That's OK. But saying "AmigaDOS doesn't track resources because it would be too expensive in memory or speed to do so" doesn't wash. -- Neil Webber / Epoch Systems, Marlboro MA / (508) 481-3717 {harvard!cfisun, linus!alliant}!palladium!nw
sneakers@heimat.UUCP (Dan "Sneakers" Schein) (01/22/89)
In Message <473@infohh.rmi.de>, shimoda@infohh.rmi.de (Markus Schmidt) writes: > >In article <89Jan14.134000est.2661@godzilla.eecg.toronto.edu> leblanc@eecg.toronto.edu (Marcel LeBlanc) writes: >>[] >> >>I'm looking for a program like the UNIX kill that will allow me to terminate >>a CLI spawned task. I'm writing some simple C code with the Lattice > >Try XOPER, it does a *fine* Job on this. Even lets you CloseScreen >or CloseWindow the reminiscents of a killed task! > Ok so where/what is XOPER ?!? I use a program called "TaskControl" (Fish 159). Its a super nice program that lets you edit a task's priority, list the current tasks to screen or printer, and make a task "wait - dead - freeze - ready". Its very nicley done and it can be reduced to a small window in the upper left corner until needed. Sneakers PS: It does not have a CloseScreen/Window feature. -- Dan "Sneakers" Schein {pyramid|rutgers|uunet}!cbmvax!heimat!sneakers Sneakers Computing 2455 McKinley Ave. Of course heimat is an Amiga. West Lawn, PA 19609 Doesn't everyone run UUCP & UseNet on an Amiga? Call: BERKS AMIGA BBS - 60+ Megs - 24 Hrs - 12/2400 Baud - 215/678-7691
sean@ms.uky.edu (Sean Casey) (01/22/89)
In article <32094@tut.cis.ohio-state.edu> Jeff Martens <martens@cis.ohio-state.edu> writes: |In article <10926@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: |>Why? Seems to me that resource allocation is an infrequently done thing. |Resource allocation is infrequently done in a language like FORTRAN |which has a static view of the world and doesn't allow users to |allocate and deallocate memory. In something more modern, like Modula |2, Pascal, Lisp, or C, this is no longer true. Consider linked lists, |trees, etc.; to manage these sorts of structures in an application |program you're continuously grabbing new memory and (hopefully) |returning it to the system when you're done with it. Even if you're |just running FORTRAN or BASIC, the translator is going to allocate |memory dynamically. I still say that resource allocation is an infrequently done thing. I use malloc(), (and brk(), and sbrk()!) on Unix just as much as the next guy. Just because the "better" languages encourage dynamic memory allocation doesn't mean it's done all the time. Yes, some applications do it all the time, but most do it infrequently. |>It also seems to me that resources could be tracked with bitmaps. Where |>is the serious speed/memory degradation? |OK. Let's keep track of every byte of RAM in the Amiga. If we allow |for 8MB of RAM, then we need an 8Mb map, which comes to a megabyte. |If we increase the granularity to, |say, a "paragraph" (Intel's term for 16 bytes if memory serves), then |8MB is thought of as 512k paragraphs, so the bitmap can fit in 64kB. Allocating memory in units this small is insane! Name an operating system that allocates in units that small! In reality, we use pages of 512 to 2048 bytes. If we use one BYTE per page, and 1K page size, we need 512 BYTES on a half meg box. That ain't bad. Keep track of EVERY byte, suuuuuure. |Of course, it's not necessary to worry about memory that's not |actually present. Assuming memory's allocated on a word basis, |though, a sixteenth of your memory's gonna be just bitmaps, and this |is pretty significant. Wrong. More like 1/500 to 1/1000 of your memory. Sean -- *** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet *** Who sometimes never learns. {backbone site|rutgers|uunet}!ukma!sean *** U of K, Lexington Kentucky, USA ..where Christian movies are banned. *** ``There's only TWO THINGS come out of Oklahoma...''
sean@ms.uky.edu (Sean Casey) (01/22/89)
In article <5748@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: > Here are some of the reasons you're wrong: resources get passed >from one process/task to another, frequently. Resources are sometimes passed >permanently, sometimes temporarily. AllocMem/FreeMem are often done for >small chunks, and very often. There are MANY resources, and orderings in which >they must be released. The system wasn't designed for it originally (or >rather the never-completed original OS did some of it (though not all). Users >allocate system structures and pass them to the system, instead of vice-versa. >We have very limited programmer resources. Improperly written programs will >leave the system potentially munged anyways, so cleaning up after them is >very risky, at best (witness GOMF - sometimes saves you, but often doesn't, or >you die a short time later). Ok so the reason resources aren't being tracked is because: 1. Resource passing makes it too complicated. 2. Memory is allocated in very small chunks. 3. There are many resources. 4. It wasn't written into the system. 5. Nasty programs can make recovery impossible. These don't seem like insurmountable obstacles, except possibly for the last. Consider running Amigados on an MMUed machine. Then #5 would be no problem at all. That's the biggest reason I'd like to see resource tracking; taking advantage of an MMU. Sean -- *** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet *** Who sometimes never learns. {backbone site|rutgers|uunet}!ukma!sean *** U of K, Lexington Kentucky, USA ..where Christian movies are banned. *** ``There's only TWO THINGS come out of Oklahoma...''
jesup@cbmvax.UUCP (Randell Jesup) (01/23/89)
In article <10938@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >In article <32094@tut.cis.ohio-state.edu> Jeff Martens <martens@cis.ohio-state.edu> writes: >|Consider linked lists, >|trees, etc.; to manage these sorts of structures in an application >|program you're continuously grabbing new memory and (hopefully) >|returning it to the system when you're done with it. >I still say that resource allocation is an infrequently done thing. I >use malloc(), (and brk(), and sbrk()!) on Unix just as much as the next >guy. Just because the "better" languages encourage dynamic memory >allocation doesn't mean it's done all the time. Yes, some applications do >it all the time, but most do it infrequently. Well, if you do the same thing under amigados (using unix-clone routines like malloc that are supplied by the compiler) you won't request resources as often. However, most malloc-clones don't release blocks that are totally free (especially since most implement the unix "bug" of free(ptr);realloc(ptr,...); being valid.) Also, mallocing system structures isn't always a good idea, especially if you're going to pass them to other tasks in the system (if your program exits, it may free the memory from under the other process - remember, lwp's with shared memory, not protected tasks communicating through the kernel.) >|OK. Let's keep track of every byte of RAM in the Amiga. If we allow >|for 8MB of RAM, then we need an 8Mb map, which comes to a megabyte. >|If we increase the granularity to, >|say, a "paragraph" (Intel's term for 16 bytes if memory serves), then >|8MB is thought of as 512k paragraphs, so the bitmap can fit in 64kB. > >Allocating memory in units this small is insane! Name an operating system >that allocates in units that small! In reality, we use pages of 512 to >2048 bytes. If we use one BYTE per page, and 1K page size, we need 512 BYTES >on a half meg box. That ain't bad. Keep track of EVERY byte, suuuuuure. AmigaDos. Many system structures are less than 40 bytes long, often as small as 14 or even 8. The system memory allocation granularity is 8 bytes. You can't afford to waste many bytes in a 512K system, of which 350-400K is free at most afer boot - larger granularities would increase the wastage when allocating all the small system structures. Remember, no VM (or MMU unless you have the new A2500 ('020, '881, '851)). Also, you need to identify which process controls the memory, so you need one table (1 bit per cell) pre process, or one global table, with 4 bytes per cell (to store the process address - we don't have artificial limits on the number of processes or open files like most Un*x's do.) You might be able to reduce that, but it's not a small thing. Also, it would slow memory allocation, which is a critical part of a real-time OS, especially on a slow processor like a 68000. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
jesup@cbmvax.UUCP (Randell Jesup) (01/23/89)
In article <10939@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >Ok so the reason resources aren't being tracked is because: > >1. Resource passing makes it too complicated. >2. Memory is allocated in very small chunks. >3. There are many resources. >4. It wasn't written into the system. >5. Nasty programs can make recovery impossible. > >These don't seem like insurmountable obstacles, except possibly for the >last. Consider running Amigados on an MMUed machine. Then #5 would be >no problem at all. That's the biggest reason I'd like to see resource >tracking; taking advantage of an MMU. Well, add not enough programmer time for why they're not being tracked currently. Big roadblock (big job) :-( A protected system would help with #5, except that the system wasn't designed for an MMU either, and depends HIGHLY on shared memory for its design and response speed. Many programs would break, even "correctly" written programs, probably. Remember, if anyone might need to look at memory you allocate, use MEMF_PUBLIC - and don't allocate such things as globals/statics in your program, since it may not be public. That will at least help a little if we go to an MMU system. Note that we only just started selling the first amiga with an MMU, 99.9+% don' have them. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
peter@sugar.uu.net (Peter da Silva) (01/23/89)
In article <619@palladium.UUCP>, nw@palladium.UUCP (Neil Webber) writes: > OK. But saying "AmigaDOS doesn't track resources because it > would be too expensive in memory or speed to do so" doesn't wash. They're not saying that. What they're saying is "You can't add resource tracking to AmigaDOS because it would be too expensive to do so without breaking existing programs." -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
rwallace@vax1.tcd.ie (01/25/89)
In article <5748@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: > In article <10926@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >>Why? Seems to me that resource allocation is an infrequently done thing. >>It also seems to me that resources could be tracked with bitmaps. Where >>is the serious speed/memory degradation? >> >>Assuming I'm right, what's the REAL reason resources aren't tracked? > > ... Improperly written programs will > leave the system potentially munged anyways, so cleaning up after them is > very risky, at best (witness GOMF - sometimes saves you, but often doesn't, or > you die a short time later). Precisely. There are two reasons for tracking allocated resources. One is so that the programmer can write his code to just exit without bothering to free resources. This isn't at all important - it's very little effort to do this, it's much more efficient to have resources freed by code that knows in advance what will have been allocated, and if the programmer is really that bothered about the hassle he can just use malloc() and simila functions for windows, files etc. which will do the job. The other reason is so you can kill a task without losing anything. You can't do this properly without hardware memory protection, otherwise there isn't much chance of the system surviving intact anyway. Hopefully Kickstart 2.0 will support hardware memory management and resource tracking... "To summarize the summary of the summary: people are a problem" Russell Wallace, Trinity College, Dublin rwallace@vax1.tcd.ie
phil@titan.rice.edu (William LeFebvre) (01/25/89)
In article <619@palladium.UUCP> nw@palladium.UUCP (Neil Webber) writes: >In Article <32094@tut.cis.ohio-state.edu> Jeff Martens adds: >>OK. Let's keep track of every byte of RAM in the Amiga. If we allow >>for 8MB of RAM, then we need an 8Mb map, which comes to a megabyte. > >No existing programs track their own memory allocations that way >(at least, I hope not!). The OS wouldn't do it that way either. >Nor would it do it in 8 or 16 byte chunks. It would do it the same >way every current program is forced to do it. It won't be ANY slower. >It won't take up ANY additional memory. I don't think so (but I'm not corageous enough to just say "WRONG"). Currently, a program asks for X bytes and gets an address (i.e.: a pointer). When it is done with it, it says "free X bytes starting at this address". Remembering that the given address is associated with a chunk of X bytes is the program's responsibility. But it's easy for the program to do so: fooptr = AllocMem(sizeof(struct foo), ...); FreeMem(fooptr, sizeof(struct foo)). The "sizeof" is a constant whose value is calculated at compile time (in assembly language, its an equated constant). Since the program knows what the pointer is used for, it knows from context how big an area the pointer points to. But if Exec is tracking the allocations for the process, Exec must, at the very least, keep an association list: (address, length). This takes extra memory. Alternatively, you could do what some Unix malloc's do: put the length at pointer-4. This still takes extra memory. Both methods also encur a fixed memory overhead per allocation, making it more efficient to do one allocation rather than many. Currently the penalty for such an approach is very, very small. I'm not trying to say that I prefer the current setup. I just think that it will take some extra memory (not much, but some). William LeFebvre Department of Computer Science Rice University <phil@Rice.edu>
iphwk@MTSUNIX1.BITNET (Bill Kinnersley) (01/26/89)
[In "Re: Task KILL for Amiga", Randell Jesup said:]
:
: written programs, probably. Remember, if anyone might need to look at
: memory you allocate, use MEMF_PUBLIC - and don't allocate such things as
: globals/statics in your program, since it may not be public. That will at
: least help a little if we go to an MMU system.
:
: Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
:
I think the reason that people don't pay more attention to MEMF_PUBLIC is
that it's never been documented precisely *which* system structures require
it. The best answer I've heard about this is "Bitmaps and sound samples
and well, lots of others (sometimes)."
--
--Bill Kinnersley
Physics Department Montana State University Bozeman, MT 59717
INTERNET: iphwk@terra.oscs.montana.edu BITNET: IPHWK@MTSUNIX1brianr@tekig5.PEN.TEK.COM (Brian Rhodefer) (01/26/89)
If calls on resource-allocation functions were made through a library of new accessing routines, it seems to me that automatic task-termination might be possible. The 'rules' of the new routines would be that petitioners must SIMULTANEOUSLY specify not only the resources that they wish allocated (memory, I/O ports, libraries, etc), but the address of a 'cleanup' function as well. The new routine would append the cleanup information to a linked list, and then pass off to the appropriate allocator. Freeing the task's resources should then simply be a matter of traversing the list backwards, calling the indicated functions to reverse whatever allocation/opening/creating/segloading/locking/etc had been done. The list nodes would probably have to also contain appropriate arguments. Since most allocatable things I can think of are ultimately represented by address pointers, it should be easy to search the list for a specific resource, and excise its cleanup node. This would allow an application to release a resource out-of-sequence, in such a way that it doesn't get re-released by an automatic task kill. Hopefully, the newsgroup's experts can explain why this tracking scheme is unworkable. Such explanations are easily more educational than double their weight in manuals, and I can obviously stand a lot more education! Rudimentally, Brian Rhodefer ..!tektronix!tekig5!brianr
jesup@cbmvax.UUCP (Randell Jesup) (01/26/89)
In article <8901251704.AA18073@terra.oscs.montana.edu> iphwk@MTSUNIX1.BITNET (Bill Kinnersley) writes: >I think the reason that people don't pay more attention to MEMF_PUBLIC is >that it's never been documented precisely *which* system structures require >it. The best answer I've heard about this is "Bitmaps and sound samples >and well, lots of others (sometimes)." True. The best answer I can give is: Anything other tasks will access, any system structure, perhaps anything intuition will use, stacks, ports, messages. If in doubt, make it public. Bitmaps and sound samples are actually a less problemsome case. They must be in chip ram anyways, and are rarely if ever (except screen bitmaps) accessed by other tasks. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (01/27/89)
In article <5799@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: [ about when to use MEMF_PUBLIC ] > The best answer I can give is: Anything other tasks will access, >any system structure, perhaps anything intuition will use, stacks, ports, >messages. If in doubt, make it public. Hmmm... I think stacks should NEVER be public, and I hope "any system structure" only means structures which will be added to an internal system list of some sort, not things like FileInfoBlocks or NewWindows. I think the RKM's description is quite reasonable: Anything that will be accessed by another task or an interrupt handler. Intuition things would need to be public if they will be accessed by the input handler side of intuition, and I don't know of a rule of thumb to know when that is the case. -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!elgar!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com
jesup@cbmvax.UUCP (Randell Jesup) (01/27/89)
In article <5808@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: >In article <5799@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: > [ about when to use MEMF_PUBLIC ] >> The best answer I can give is: Anything other tasks will access, >>any system structure, perhaps anything intuition will use, stacks, ports, >>messages. If in doubt, make it public. > >Hmmm... I think stacks should NEVER be public, and I hope "any system >structure" only means structures which will be added to an internal system >list of some sort, not things like FileInfoBlocks or NewWindows. FileInfoBlocks and NewWindows are probably ok. Stacks must be public if you plan to call anything that might use a Dos call OR call anything that might use SignalSemaphores. This is, of course, all speculation, and all the MEMF_PUBLICs in the world won't guarantee your program will work if we do a protected mode OS, but they certainly give your program a much better chance! >Intuition things would need to be public if they will be accessed by the >input handler side of intuition, and I don't know of a rule of thumb to >know when that is the case. Which is why I was vague. Even if I gave a list, it might change tomorrow (or at least next time we release an OS upgrade). -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
MJB@cup.portal.com (Martin J Brown-Jr) (01/27/89)
It's been awhile since a lingering or hung up program needed to be killed on
my A1000, but last night "archa" got hungup unzoo'ing a bad file and wa
eating up cpu time pretty good. "Xoper" to the rescue. I cancel'd the offend'g the offending
ing
process number "6 Background CLI" (case sensitive). The archa window dis-
appeared and the system sluggishness was gone. It's been running fine these
past 24hrs. (knock on wood :-> ). The only "hard" part was figuring out
from xoper lists of processes which was the one that I wanted to cancel.
Luckily, archa was the next to last thing I started (xoper was the last), and
was a fairly easy guess as to what needed to be specified in the cancelance
command. Xoper seems to be able to kill at least some tasks.
- MJB -cmcmanis%pepper@Sun.COM (Chuck McManis) (01/28/89)
In the referenced articles Randell and Michael were debating where one
might want to truely use the MEMF_PUBLIC flag. Generally, in the Amiga
MEMF_PUBLIC has little or no use. What they seem to be overlooking is
that there is a large degree of difference between tasks/processes and
"context". In the future version of "Exec" that extends control to an
MMU based system, what will be important is what "context" the task is
running in, rather than what task the pc happens to be sitting in.
Essentially, some tasks such as handlers and I/O devices share the
same context as all of their client tasks. So when you go to Examine
a file or read the joystick the message you pass remains in your context
(and hence your address space) and thus the other task has no problem
reading or writing it. When a reply is sent, the context is established
first so that you can be sure the reply will go to the correct place.
Think of the Amiga as operating in a single context today. Tomorrow,
that context information may be changed on the fly but the programs
will still work.
--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.nw@palladium.UUCP (Neil Webber) (01/28/89)
In article <619@palladium.UUCP> I wrote: >It would do it the same way every current program is forced to >do it. It won't be ANY slower. It won't take up ANY additional memory. referring to the OS keeping track of memory allocations. In article <2477@kalliope.rice.edu> phil@Rice.edu (William LeFebvre) pointed out a possible counter-example: >Currently, a program asks for X bytes and gets an address (i.e.: a >pointer). When it is done with it, it says "free X bytes starting at this >address". Remembering that the given address is associated with a chunk >of X bytes is the program's responsibility. But it's easy for the program >to do so: fooptr = AllocMem(sizeof(struct foo), ...); >FreeMem(fooptr, sizeof(struct foo)). This is a legitimate counter example, given the way I worded my claim. In the fine USENET tradition, I glossed over too many details. I was referring to what calls (such as malloc()/free()) layered on top of AllocMem/FreeMem already do to return all the memory to the OS upon program exit. In the case of calling AllocMem/FreeMem directly, the overhead is less obvious, but still there. The call: FreeMem(fooptr, sizeof(struct foo)) takes up memory. For any given application program we could compute the overhead implicit in all the FreeMem calls. This computation would be tricky: sometimes one FreeMem call code can serve to free multiple pieces of memory (if the call is in a loop, or in a shared pure procedure). Sometimes there will be multiple FreeMem call code instances for serving a single piece of memory (i.e., FreeMem calls duplicated in error path cleanup). Another (very real) form of memory overhead is when an application forgets to call FreeMem :-) What I'm really getting at is that you have to consider the entire system when assessing the tradeoffs for and against a given feature. The lack of resource tracking, in my opinion, has the *appearance* of making the system faster and smaller. I believe that when you take the entire system, including application programs, into account, you would find that the advantage is largely an illusion. And, as we all know, there are concrete disadvantages: - no KILL - increased burden on application developers. Have you spent any time tracking down "where did I forget to free this memory" bugs? That's part of the cost of no resource tracking. And it is multiplied by a large (one hopes) development community. I don't realistically expect any future Amiga OS to include resource tracking, unless it represents a major change from the current system. I do, however, cringe whenever I see someone claim that the current system is desirable because it is faster and more memory efficient. -- Neil Webber / Epoch Systems, Marlboro MA / (508) 481-3717 {harvard!cfisun, linus!alliant}!palladium!nw
shimoda@infohh.rmi.de (Markus Schmidt) (01/29/89)
In article <3719@tekig5.PEN.TEK.COM> brianr@tekig5.PEN.TEK.COM (Brian Rhodefer) writes: > >If calls on resource-allocation functions were made through a >library of new accessing routines, it seems to me that automatic >task-termination might be possible. The 'rules' of the new routines >would be that petitioners must SIMULTANEOUSLY specify not only the >resources that they wish allocated (memory, I/O ports, libraries, etc), >but the address of a 'cleanup' function as well. The new routine would >append the cleanup information to a linked list, and then pass off to >the appropriate allocator. > Reading this I remember, that a Task-Structure contains a Cleanup_Code pointer. However documentation about it is bad. What does the Standard-Cleanup do, and how do I (from "C") install my own CleanupCode? My Programs always have a central Cleanup-Code that cleans up everything, if called from every point in the Program. So how do I get it there? Cu Markus .-----------------------------------------------------------------. | shimoda@rmi.de `---' The last remaining adventure | | shimoda@gopnbg.UUCP |O o| since there are no more tigers: | | ==Y== Doublebuffered async. I/O _ | |----------------------- `U' ------------------------------ _ // | | Good terminalpackages begin with A: AmigaCall, A-Ta.. \// | `-----------------------------------------------------------------'
shimoda@infohh.rmi.de (Markus Schmidt) (01/29/89)
In article <31269@vax1.tcd.ie> rwallace@vax1.tcd.ie writes: >surviving intact anyway. Hopefully Kickstart 2.0 will support hardware memory >management and resource tracking... Hopefully there's anyone in the amiga-family able to write suiting code, and anyone who will use KS2.0, when all the software you love breaks. .-----------------------------------------------------------------. | shimoda@rmi.de `---' The last remaining adventure | | shimoda@gopnbg.UUCP |O o| since there are no more tigers: | | ==Y== Doublebuffered async. I/O _ | |----------------------- `U' ------------------------------ _ // | | Good terminalpackages begin with A: AmigaCall, A-Ta.. \// | `-----------------------------------------------------------------'
jesup@cbmvax.UUCP (Randell Jesup) (01/30/89)
In article <87289@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >In the referenced articles Randell and Michael were debating where one >might want to truely use the MEMF_PUBLIC flag. Generally, in the Amiga >MEMF_PUBLIC has little or no use. What they seem to be overlooking is >that there is a large degree of difference between tasks/processes and >"context". In the future version of "Exec" that extends control to an >MMU based system, what will be important is what "context" the task is >running in, rather than what task the pc happens to be sitting in. >Essentially, some tasks such as handlers and I/O devices share the >same context as all of their client tasks. So when you go to Examine >a file or read the joystick the message you pass remains in your context >(and hence your address space) and thus the other task has no problem >reading or writing it. When a reply is sent, the context is established >first so that you can be sure the reply will go to the correct place. >Think of the Amiga as operating in a single context today. Tomorrow, >that context information may be changed on the fly but the programs >will still work. I think you're being a little bit over-presumptious about a protected Exec. You'll also note that I said that memory other tasks would access. I should have been more clear, I meant other "user" tasks. Handlers and devices are system tasks, and can run unprotected if need be, or in supervisor mode. The danger is in allocating things that will be put on system lists as public, where other people can find them. Ports (and the names they use!) are a good example of this, if they're made public. Private ports (not on the port list) should still be in public memory if you're going to send messages to a non-system task (since it will reply). And of course memory/structures pointed to by messages should be public. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
peter@sugar.uu.net (Peter da Silva) (01/30/89)
In article <620@palladium.UUCP>, nw@palladium.UUCP (Neil Webber) writes: > What I'm really getting at is that you have to consider the entire > system when assessing the tradeoffs for and against a given feature. > I do, however, cringe whenever I see someone claim that the current > system is desirable because it is faster and more memory efficient. Agreed, but before people misunderstand you, it is not possible to add resource tracking to the system. Example: Task A allocates a bitmap. Task A passes the bitmap to task B. Task B opens a screen with the bitmap as its CustomBitmap. Task A exits. At this point, if you track resources, the system gurus. Task A will have to call "ReleaseOwnership(bitmap)", and task B will have to call "AssumeOwnership (bitmap)". These calls are not in any current applications (for the simple reason that they do not exist). QED. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
deven@pawl.rpi.edu (Deven Corzine) (01/30/89)
well, it seems it should be simple enough to patch library calls such as allocmem, freemem, openlibrary, closelibrary, etc. to track resources intelligently, and patch remtask, i suppose, to make sure everything was deallocated/closed. either it could just close and free everything left before removing the task, which has the clear liability of breaking programs which *intentionally* leave the memory allocated (to be freed by some other task) or a library open (to lock it in memory) or whatever. Alternatively, the tracker could alert the user that resource _____ is still allocated, and allow the user to decide whether to force release of none, some or all of the resources, as he or she sees fit... Of course, this could get annoying for the user, so configuring it to take specific actions for specific programs by default would be helpful, along with the ability to fully uninstall the tracker, or to make it run silently, without harassing the user, perhaps compiling a list of "naughty" programs. The best use would be fully interactive mode for testing and debugging programs, so that the programmer could fix (or try to fix, at least) resource allocation holes before using (and possibly releasing) the programs. Does this sound feasible, or have I been hypnotized by this flickering interlaced screen? Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.
dan@ivucsb.UUCP (Dan Howell) (01/31/89)
In article <32094@tut.cis.ohio-state.edu> Jeff Martens <martens@cis.ohio-state.edu> writes: |In article <10926@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: | [ stuff deleted ] |>It also seems to me that resources could be tracked with bitmaps. Where |>is the serious speed/memory degradation? |OK. Let's keep track of every byte of RAM in the Amiga. If we allow |for 8MB of RAM, then we need an 8Mb map, which comes to a megabyte. |The alternatives are to increase the granularity of our map or keep it |on disk. It won't fit on a floppy, and even on a hard drive |performance would be hampered. If we increase the granularity to, |say, a "paragraph" (Intel's term for 16 bytes if memory serves), then |8MB is thought of as 512k paragraphs, so the bitmap can fit in 64kB. |This is still a considerable amount of memory, and results in wasted |space if the user doesn't use memory in 16 byte chunks. Seems to me you could use a concept known as private heaps, where a process would allocate a heap in chunks of 1k or so (which the OS would keep track of with a bitmap). Then the process would be able to allocate small pieces of this heap at a time, and if it needs more than 1k, the OS automatically increases the size of the heap. Then when the process dies, the OS automatically deallocates the heaps associated with that task. -- Dan Howell <...!apple!comdesign!ivucsb!dan> <dan@ivucsb.UUCP>