barsh@stsci.EDU (John Barshinger) (01/08/88)
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??
It seems like task2 should be allowed to access the main process
memory utilizing the Forbid, Permit sequence, is this correct?
This is what I had been doing:
in task2 - guru city - :-<
igwin is a pointer to the gadget window in the main process
if ((sigbit = AllocSignal(-1)) != -1)
{
Forbid();
igwin->UserPort->mp_SigBit = sigbit;
igwin->UserPort->mp_SigTask = FindTask(0);
Permit();
}
msg = WaitPort (igwin->UserPort);
The sole purpose of all this is so that when my program is off
doing its thing, the gadget will still get serviced and do its
thing. (kinda like the Depth gadgets, no matter what the program
is doing, the Depth arrangements still arrange depths).
If anyone has any other/easier ways to accomplish this, I'm all
ears...
thanx,
jrbii
~~~~~
--
John Barshinger
Space Telescope Science Institute
Baltimore, MD 21218
plink:jrbii | bix:jrbii | barsh@stsci.eduewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (01/09/88)
In article <183@ra> barsh@stsci.EDU (John Barshinger) writes: >To a task/port GURU: > I'm not a Guru, but I play one on TV.... :-) >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?? > This scenario as you describe it is not possible (task 2 allocates nothing, therefore frees nothing when RemTask()ed). In order for Intuition to Signal() you, you *must* allocate a signal bit (AllocSignal()). Consequently, you must free it before your task exits. Since you're doomed to allocating at least the signal, you may as well open the whole window.... _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ 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
barsh@stsci.EDU (John Barshinger) (01/10/88)
in article <4943@well.UUCP>, ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) says: > > In article <183@ra> barsh@stsci.EDU (John Barshinger) writes: >>To a task/port GURU: >> > I'm not a Guru, but I play one on TV.... :-) > >>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?? >> > This scenario as you describe it is not possible (task 2 allocates > nothing, therefore frees nothing when RemTask()ed). In order for Intuition > to Signal() you, you *must* allocate a signal bit (AllocSignal()). > Consequently, you must free it before your task exits. > > Since you're doomed to allocating at least the signal, you may as > well open the whole window... According to Rob Peck's book, Programmers Guide to the Amiga, task2 can AllocSignal and not have to FreeSignal since the task will be removed and task's signals are in each task, he says, why bother, seems reasonable to me... The above book has been very useful in my efforts in this, I have all of the RKM books, but sometimes they aren't very complete on descriptions. I also ordered and got his disk with all the book examples on it, this is also very useful, There are even some extra things on the disk that are kinda neat, but I have found that some examples in the book didn't make it to disk :-(. But I highly recommend the book, even if you have all ROM Kernal Manuals... Anyway, back to the main topic, Since we were all snowed in and got Friday off here in Baltimore. I was able to spend the whole day visiting the guru and finding the answers to the questions in my first posting. I'm modifying my version of VT100 to use Leo's iconify, but I want the iconify gadget to work even when I'm downloading so that I can leave my screen and go on to do other stuff. Then d-click the VT100 icon and check its progress, etc. So after modifying iconify, so that is runs as a separate task that waits for the iconify gadget to be clicked, then removes the VT100 screen from the display, then does its thing (makes the VT100 gadget on the WBENCH screen, and waits for the d-click ), then it returns VT100 to the screen, etc. This is a more useful way for iconify to work for me in this application, what do you think? jrbii ~~~~~ p.s. I will probably send this to moderators in the next few days, it will also be available on PeopleLink... -- John Barshinger Space Telescope Science Institute Baltimore, MD 21218 plink:jrbii | bix:jrbii | barsh@stsci.edu
rmariani@watmum.waterloo.edu (Rico Mariani) (01/11/88)
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