Path: utzoo!utgpu!water!watmath!watcgl!watmum!rmariani
From: rmariani@watmum.waterloo.edu (Rico Mariani)
Newsgroups: comp.sys.amiga
Subject: Re: To any Task/Port/Window Gurus (Help)
Summary: This is not a good way to do it
Message-ID: <2881@watcgl.waterloo.edu>
Date: 11 Jan 88 04:33:51 GMT
References: <183@ra>
Sender: daemon@watcgl.waterloo.edu
Reply-To: rmariani@watmum.waterloo.edu (Rico Mariani)
Organization: U. of Waterloo, Ontario
Lines: 50

In article <183@ra> barsh@stsci.EDU (John Barshinger) writes:
>To a task/port GURU:
>
>I would like my main process to open two windows, one for typical
>output and the other for a gadget.  I am creating a task in my program
>for the sole purpose of responding to the second window/gadget.  Is
>there any way to fake out the Amiga to set a signal bit in task2
>so that I can just wait for it as if task2 had opened the window.
>I realize that I could just open the window in task2, but then I would
>need to create more ports (and use more memory, etc) just to send messages
>to terminate the program and synchronize closing the windows before closing
>the custom screen. (if I don't open/allocate anything in task2, when main
>terminates, Task2 will also go away without any adverse effects, right??

No.  Task 2 has its very own thread and will continue to run even if
the memory it is running in is UnLoadSeg'd right out from under its
feet.  You must somehow arrange for Task 2 to terminate itself or
be terminated by the main before exiting.  I would really recommend
that you let Task 2 open its own windows and create a message port
for the express purpose of telling Task 2 to go away from the main.
This will save you much aggrevation.  

As for redirecting the window messages I think you're doing the right
thing (if you really want to do it that way).  You should be able
to change the signal bit and task field of the Port structure and
have things work OK.

>It seems like task2  should be allowed to access the main process
>memory utilizing the Forbid, Permit sequence, is this correct?

Well... be careful.  You have really got to watch out if you call
any C library routines like malloc/free or stdio functions like
printf.  These all expect there to be only one task using them
and therefore the functions are not re-entrant.  There are static
stdio buffers and so forth that are used behind your back.  No
problem if only one task is using them but if several tasks
start trying to use the same static buffers --POOF--.  Same
goes for malloc/free.  There is only one to-free list maintained
by malloc and malloc is likely not re-entrant.  You must use
only kernal calls (which are all re-entrant) in your sub-task.

I couldn't see anything wrong with your code segment that does the
port fooling and waiting but I don't think that is where the problem
lies.  You've got to watch out for lots of other things when running
two tasks in the same loaded segment (see above).  Are you doing
the geta4() thing if you're using Manx?  Are you making any DOS
calls from your Task?  If so you need to create a full process
not a task.

	-Rico