🚀 go-pugleaf

>(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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~