Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!cbmvax!higgin From: higgin@cbmvax.cbm.UUCP (Paul Higginbottom GUEST) Newsgroups: comp.sys.amiga Subject: Re: MANX bugs with Tasking (the REAL fix) Message-ID: <1169@cbmvax.cbmvax.cbm.UUCP> Date: Tue, 23-Dec-86 19:14:34 EST Article-I.D.: cbmvax.1169 Posted: Tue Dec 23 19:14:34 1986 Date-Received: Wed, 24-Dec-86 20:47:12 EST References: <2226@bacall.UUCP> <865@ulowell.UUCP> Reply-To: higgin@cbmvax.UUCP (Paul Higginbottom GUEST) Organization: PDH, Inc. Lines: 83 In article <2233@bacall.UUCP> papa@bacall.UUCP (Marco Papa) writes: >I write: >> > >>Has anybody gotten tasking to work with MANX? [...cut] >> > >>-- Marco Papa > >Phillip Lindsay writes: >> This is a problem related to the A4 register used as a base register, I believe >> the problem is apparent in the small-code/data models and not in large code/data >> models. (ie. "cc +cd foo.c" will compile using large models) >> Large model won't work if you want to use anything in the linkable libraries which were compiled "small model". >> In the interest of people screaming about Manx and tasks I make the following >> re-posting from well!crunch: (I don't think crunch and manx will mind...) >> >> AMIGA-MANX-FIX follows > This fix wasn't quite right since (at least under 3.30e) the front end already contains a geta4() routine and saves a4 off automatically. By front end I mean crt0.a68 which is linked in the front of every C program written (along with _main.c). So, all you need to do is: geta4(); as the first thing in your task. The REAL problem however, is as follows, and this doesn't have anything to do with Manx. You'll note in the DeleteTask() source (in RKM v2) that it says "doesn't handle self-deletion properly." Well I'm not surprised. To get a task started, you simply alloc a task structure and a stack for the task, init the task structure, and call AddTask either with a starting pc of some function in the program itself (basically making a sub-task part of the same progra), or with a shifted BPTR returned from a LoadSeg'ed program module (which will need a special front end by the way, or it won't get hopping, but that's another issue). Anyway, supposing you have a task running - how does it end? When it "rts"'s - Exec does a RemTask if you don't have some special cleanup code, but HOW is the task structure and stack going to be freed? If it is done by the parent (the program that created it), how is the parent to know when the child (sub task) has finished? The only way I can think of is that the parent must create a message port, and the child sends of a message saying "I'm finished" just before ending, so that once the parent receives the message (which it WON'T reply to of course), it can then go ahead with freeing up the stack and task structure. This to me still isn't ideal - I'd like to be able to get a task going and let the task deal with termination itself, i.e., exist independently, without the need for the parent to stick around to cleanup after its offspring (how metaphoric). I'd like some ideas on this if anyone has any. Summary ------- I can create a task, but without going to the message port solution outlined above, the program loses the memory allocated for task structure and stack every time because the parent can't free it (through not knowing when the child has finished). I tried having the optional FinalPC code do it for the child, but (I guess) as soon as it tries to free its own stack, its history (i.e., guru). Aside, Best Wishes to all and their Amigas over the Holiday season. Paul Higginbottom. Disclaimer: I work for myself, and my opinions are my own. >Thanks Phil! Why this didn't get fixed in the beta 3.30e, I don't know. >Hopefully it will be fixed in 3.40. Now the problem. Does the patch works >also if done before/after CreateTask (which calls AddTask)? If it does not, >then only people like me that have the "source" for CreateTask can fix it. >I will try this tonight and see what happens. > >-- Marco Papa > Felsina Software