schifala@udel.EDU (Jim Schifalacqua) (03/08/88)
Hello, I am trying to design a neat way to kill tasks spawned by my programs. I want to use exception processing via SetExcept and the tc_ExceptCode field. What I mean to do is point tc_ExceptCode at my cleanup routine and use SetExcept to point a signal that will start thisup from within my task. My question is how will the system react to a RemTask() call from within the exception? The more I think about this the more it seems to me that I am going to crash the system- what is the true wisdom on this? Thanks!
dillon@CORY.BERKELEY.EDU (Matt Dillon) (03/08/88)
>Hello, > I am trying to design a neat way to kill tasks spawned by my programs. >I want to use exception processing via SetExcept and the tc_ExceptCode field. >What I mean to do is point tc_ExceptCode at my cleanup routine and use >SetExcept to point a signal that will start thisup from within my task. >My question is how will the system react to a RemTask() call from within the >exception? The more I think about this the more it seems to me that I am >going to crash the system- what is the true wisdom on this? > >Thanks! Since the exception handler runs in user mode in the task's context on the task's stack, you should be able to RemTask(NULL) fine.... of course, the only way to find out is to try! There is a major problem though, that you don't want to kill a task while it is in the middle of a library call. Usually, one needs a more synchronous way of killing a dedicated child task... in the above method, you are not guarenteed that the task will be killed immediately after you send the Signal(). I usually do it it like this: Totally synchronous method: Use one of the preallocated signals to mean "please die", and signal the task in question with that signal. The task would then Forbid(), signal you back, and RemTask(NULL) (while still forbid()en). When you get the signal back, the task is guarenteed to not exist anymore and you can clean up its resources (memory, seglist...) -Matt
cmcmanis%pepper@Sun.COM (Chuck McManis) (03/09/88)
In article <1406@louie.udel.EDU> schifala@udel.EDU (Jim Schifalacqua) writes: >Hello, > I am trying to design a neat way to kill tasks spawned by my programs. >I want to use exception processing via SetExcept and the tc_ExceptCode field. If I may suggest an alternative? It is generally not nice to kill tasks forcibly on the Amiga. It leads to all sorts of race conditions, vis-a-vis freeing resources, stopping I/O, etc. A much cleaner solution is to give your task a message port that it monitors. When you want it to die, send it a kill message. It would then clean up and reply. After the reply you could RemTask(), it. --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.
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (03/09/88)
[ Personally, I'd like to see it called comp.sys.amiga.wizards.... ] In article <1406@louie.udel.EDU> schifala@udel.EDU (Jim Schifalacqua) writes: >Hello, > I am trying to design a neat way to kill tasks spawned by my programs. >I want to use exception processing via SetExcept and the tc_ExceptCode field. >What I mean to do is point tc_ExceptCode at my cleanup routine and use >SetExcept to point a signal that will start thisup from within my task. >My question is how will the system react to a RemTask() call from within the >exception? The more I think about this the more it seems to me that I am >going to crash the system- what is the true wisdom on this? > The True Wisdom is: Don't do it. I tried pulling this trick in a program I wrote. Academically, it is, indeed, possible to asynchronously pop out of a program using an exception, and then longjmp() out of it if you want. However, from a practical standpoint, this is riddled with problems. Among these is freeing up resources that you may have (invisibly) allocated. Suppose you draw a line. The sequence for making any use of the blitter is: OwnBlitter (); WaitBlit (); StompBlitterRegisters (); StartBlitter (); DisownBlitter (); The Own/DisownBlitter() calls are invisible to you, but they still exist. If you take an exception while stomping the blitter registers (you own the blitter), and then asynchronously exit from the program, you will still own the blitter. Since you no longer exists, the blitter is owned by no one, and no one can free it. So the system stops. This problem applies to semaphores in general. Unless you are *ABSOLUTELY CERTAIN OF WHAT YOU ARE DOING*, don't use exceptions except in a "subroutine" capacity. They are quite handy, though, once you know what to avoid... _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Recumbent Bikes: dual ---> !{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 Doctor