Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!amdahl!pacbell!well!ewhac
From: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Shared IDCMP Ports--Proposal
Message-ID: <7439@well.UUCP>
Date: 22 Oct 88 08:36:14 GMT
References: <3031@amiga.UUCP> <7412@well.UUCP> <3037@amiga.UUCP>
Reply-To: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Organization: Klein Bottle Wanted; Inquire Within.
Lines: 56
Quote: "'Just try trusting me' -- that's weak even by his standards."  -- Avon

In article <3037@amiga.UUCP> jimm@cloyd.UUCP (Jim Mackraz) writes:
>In article <7412@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
>The proposal is for how you might be ABLE to register the same port
>for IPC as you are using for IDCMP, whether you create/delete it or
>does Intuition.  I think this is the misunderstanding.
>
	Oh, I get it.  IPC can occur through any port I care to name,
including the IDCMP port if I so desire.  And I won't get IPC messages
unless I register my port.

	I guess the reason I'm having difficulty understanding all this in
one pass is that I've had my own vision of an IPC system for some time, but
I guess I never imparted it correctly, because no one seemed to like it.

	My vision was that *every* program would respond to a defined set of
coded commands (read, write, stop, etc.).  The idea was that all programs
would respond in the appropriate way when sent the command.  This means that
you could write a script that did a generic thing, and apply it to all the
programs you had without modifying it.

	Since all programs would be doing this, and all programs obeyed the
same exact commands, connection would take place through the pr_MsgPort.  To
send a command to a program, you'd look it up in Exec's list of running
tasks (checking to be sure it's a process first), and send it a command.

	Well, *I* thought it was neat...

>)	win = FindWindowUserClickedIn ();
>)	pr = (struct Process *) win -> UserPort -> mp_SigTask;
>
>ARRGH ARRGH ARRGH!!!  (exclamation of some concern)
>
>Nobody says that the port you use for IDCMP must be created by Intuition,
>nor that it must be PA_SIGNAL.  That is to say, NO REASON TO ASSUME THAT
>mp_SigTask is a valid task (and even then no reason to believe it
>is a process).
>
	Oh, great.  Does this mean Intuition uses some other method of
Signal()ing me when a message is ready?

>)	case default:
>)		die ("OOPS!  Unknown IDCMP msg received.\n");
>
>Now, I don't think this is too wise, in the interest of robust code.
>Not much weirder than the Guru Meditation, I suppose, ...
>
	I usually put it in for debugging reasons, and then never bother to
take it out since it's "never" going to get called anyway.  It's helped *me*
out on a few occasions.  And my die() routines are scientifically designed
to kill the program coherently, leaving you with a useable machine.
So there.	:-)

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape	INET: well!ewhac@ucbvax.Berkeley.EDU
 \_ -_		Recumbent Bikes:	UUCP: pacbell > !{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