Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!oliveb!amiga!jimm
From: jimm@amiga.UUCP (Jim Mackraz)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Shared IDCMP Ports--Proposal
Message-ID: <3051@amiga.UUCP>
Date: 23 Oct 88 22:57:43 GMT
References: <3031@amiga.UUCP> <7412@well.UUCP> <3037@amiga.UUCP> <7439@well.UUCP>
Reply-To: jimm@cloyd.UUCP (Jim Mackraz)
Organization: Commodore-Amiga Inc, Los Gatos CA
Lines: 110

In article <7439@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
)In article <3037@amiga.UUCP> jimm@cloyd.UUCP (Jim Mackraz) 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.

Perhaps the original article should have been sub-titled: "How to use your
IDCMP port for other things, or a port you created for IDCMP."

)	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,

Freeze it here, Eddie.  I am all for common command sets, but we don't have
them.  Also, people are using IPC for things are beyond the reach of any
common command set.  I'm working here on a minor technical point of
what the options are at the lowest application level.

)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.

It shouldn't matter too much where people receive universal commands.
Using a port that happens to be around is sort of "registering a port
by side-effect," and it isn't much more complicated to separate the
"registration" from the "being a task."  After all, while making a standard
for IPC commands, you can certainly impose a standard place to find
target ports for addressing the commands.

For historical reasons and probably others, decoupling task/port is
important because there isn't a 1:1 correspondence between pr_MsgPort
and IPC participants.

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

The idea of sending standard IPC messages to applications as a matter
of standard operating procedure IS 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?

Intuition DOES NOT signal you.  It sends you message.  Exec signals you,
initiates a software interrupt, or just AddTail's the message.  For that
matter, it COULD invoke the dreaded ACTION_3!!    What THEN??

Just dig this bad vibes from exec/types.h:

    "#define mp_SoftInt mp_SigTask"

)>)	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 Schwab, Software Assassin.  I like it it.  It has a good beat and you
can dance to it.

There are no plans to send IDCMP messages to a program which doesn't
request them.  Your approach should continue to work.

What I put in my default case is:

    default:
	serout = fopen( "ser:", "w" );
	fprintf( serout, "atdt14085553303\n");
	fprintf( serout, "guru\nbloodlust\n");
	fprintf( serout, "mail jimm\n");
	fprintf( serout, "Someone sent me an unrecognized IDCMP message!!\n.\n");
	fprintf( serout, "logout\n");
	fprintf( serout, "ath\n");
	Alert( AN_DOSNOMEMORY );

	jimm

)Leo L. Schwab -- The Guy in The Cape	INET: well!ewhac@ucbvax.Berkeley.EDU
-- 
	Jim Mackraz, I and I Computing	  
	amiga!jimm	BIX:jmackraz
Opinions are my own.  Comments regarding the Amiga operating system, and
all others, are not to be taken as Commodore official policy.