angst@batserver.cs.uq.oz.au (Angst) (08/23/90)
My colleague and I are writing an Amiga interface for a functional language (a fully lazy version of Hope). We would like to be able to service intuition events without having to poll the message ports periodically, i.e. we would like intuition events to generate software interrupts. I have a feeling this is possible (since there are parts of the Intuition message passing hierarchy that mention software interrupts) but I can't work out how it all fits together. Can anyone help ? If it turns out that what we desire is not supported in WB1.3, then how about this for an alternative. The master process creates a child that does all the actual work of the Hope interpreter. Meanwhile, it sits around polling the message port and acting upon any events appropriately. Problems I can see with this : + how do we kill the child when an event (i.e. quit) so requires; + how do we suspend the child when an event (i.e. inconify) so requires; + how do we get the child to attach its console (for screen I/O will be handled by the child) to the same window for which the master is polling ? The BYTE review mentioned a mysterious addition to WB2.0 called "HotLinks". Does this handle this kind of process control ? Angst p.s. RTFM Angst !! p.p.s. Beat you to it. ---------- "Tell the King that he's as safe as a fox being hunted by a pack of one-legged hunting tortoises." -- Lord Edmund Blackadder, loyalist -----------------
markv@kuhub.cc.ukans.edu (08/23/90)
>(a fully lazy version of Hope). We would like to be able to service intuition > events without having to poll the message ports periodically, i.e. we would > like intuition events to generate software interrupts. > > I have a feeling this is possible (since there are parts of the Intuition > message passing hierarchy that mention software interrupts) but I can't work > out how it all fits together. Can anyone help ? I *think* (not having my RKMs at work and not having done this myself), that it is a matter of setting the PA_SOFTINT flag on your window's message port, and filling in another field to point at the interrut code. > If it turns out that what we desire is not supported in WB1.3, then how about > this for an alternative.The master process creates a child that does all the > actual work of the Hope interpreter. Meanwhile, it sits around polling the > message port and acting upon any events appropriately.Problems I can see with > this : > + how do we kill the child when an event (i.e. quit) so requires; > + how do we suspend the child when an event(i.e. inconify) so requires; I've had a similar problem in several programs. I spawn off a child task to poll the IDCMP port (using WaitPort()). I write the child as a C function that loops forever, and spawn it off using CreateTask(). When it figures out that it is time to die, it does a Wait(0L); which puts it in a permanantly non-executing state so that it is safe to kill it with DeleteTask(). If you want the child to wait indefinitely but synchrounusly on some event (without busy waiting which is a no-no) have the child allocate a signal and stores it's task ID like this: BYTE MySignal; struct Task *ChildTask; { MySignal = AllocSignal(-1); /* We'll take any signal */ ChildTask = FindTask(NULL); MySignal is the *number* of the bit that is that signal. The TaskID is also returned by CreateTask. These examples assume using shared global variables (if using base-relative addressing under lattice, the function that is the child task needs to fetch the global data base, either with the __saveds keywork, the -y compiler option, or the geta4() function). The child can than wait on the signal like this: Wait(1L << MySignal); You can also Wait on several signals at one time since Wait() takes a bit mask of all signals to wait on, like this example of the IDCMP port and our signal: ULONG SignalMask; SignalMask = Wait((1L << MySignal) | (1L << OurWindow->UserPort.mp_SigBit)); You can check which signal(s) (could be more than one) woke you up by checking which bits are set in SignalMask. You can also check and clear signals without blocking like this: SignalMask = SetSignal(0,0); The parent signals the child like this: Signal(ChildTask, (1L << MySignal)); Just remember that signals are Task specific, so they need to be allocated in the task that is to *receive* that signal. You should also FreeSignal() the signal when you are done. > + how do we get the child to attach its console (for screen I/O will be > handled by the child) to the same window for which the master is > polling ? You can open a console on an existing window by filling in specific fields in the correct structures (I dont remember the details here). If using an IDCMP port for input on a window it is best to open the console for writing only, otherwise you run into somewhat fuzzy conflicts over who gets input to your window, you or console.device. Just remember if you child is a TASK and not a PROCESS it can not do any DOS I/O (or any calls that might result in DOS I/O like OpenLibrary(), OpenDiskFont(), etc). Your main program (which will be a process) should do this for the child task. So for instance, the child can access console.device, but NOT a CON: file handle. > The BYTE review mentioned a mysterious addition to WB2.0 called "HotLinks". > Does this handle this kind of process control ? Not really sure myself... The file system has both hard and soft links (ala Unix) under 2.0. There is also some kind of facility for being posted info about dynamic changes that a program is interested in (I think along the lines of behavior of the NEWPREFS IDCMP flag). > ----------------- -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: markgood \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~