vansickl@bnr.ca (Greg VanSickle 1561848) (03/27/91)
I found the Arexx article (An Introduction to Interprocess
Communication with ARexx) in AC'sTech Amiga to be very good.
However, after explaining the virtues of multitasking and
encouraging readers to write rexx routines that open up message
ports, (eventually resulting in the user having a library
of useful routines,) the author does a curious thing.
He gives two examples of rexx routines talking to each
other. In the first, program simple1.rexx runs
simple2.rexx and, after a delay, sends messages to it.
Simple2.rexx opens a port and receives the messages sent
by simple1. The port name is coded in the programs.
The second example also codes the port name.
Can this not lead to problems? Does this prevent a third
program from also starting a simple2.rexx and sending it
messages? It also would appear to result in pairs of rexx
routines that must be used together, rather than a collection
of routines that can be intermixed as needed.
IMHO, it would make sense to write simple2.rexx to accept
the portname as an arguement. Any other rexx program that
wanted to use simple2.rexx could create a unique identifier
from, say the date or some process number (any good
suggestions?) and pass it to simple2.rexx at it's invokation.
This way, any program could use as many runs of simple2.rexx
as it needed without concern of what other programs are doing
with it, or, conversely, many programs could talk to the same
run of simple2.
Am I missing something ?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Geg VanSickle Silicon Support
Bell Northern Research phone: 613-763-5160
PO Box 3500 ESN: 393-5160
Nepean, Ontario, Canada
K2H 8V4 cocos: Greg Van Sickle
email: vansickl@bnr.ca
---------------------------------------------------------------------
Vancouver van cu' ver n. where we should all be, as opposed to
where I am
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=giguere@csg.uwaterloo.ca (Eric Giguere) (03/28/91)
Though I haven't seen the article in question, the original poster
is quite correct in that hard-coded port names can lead to problems.
It's not a simple problem, though, and it shows up in any system
with some kind of public interprocess communication: how do I identify
an IPC port?
The ARexx resident process (the REXX server) is a good example. Running
ARexx programs and host applications NEED to know how to locate it so
that they can sent it messages. So the resident process opens two ports
("REXX" and "AREXX") as its "mailboxes". The names are well-known and
won't change. This solution works quite nicely because only one copy of
the resident process will ever be running at any given time. (It's easy
to check, too -- just see if the port you want to allocate has already
been allocated...)
But then there's the case of programs that can be run multiple times.
What should you do then? Let's take a text editor as a classic example.
A text editor could be run twice, and each copy can open one or more files
for editing. The solution advocated in the Amiga User Interface Style
Guide is to open an ARexx port for each open document, with each ARexx
port being of the form
<APPNAME>.<NUMBER>
where APPNAME is the base application name ("MYEDIT") and NUMBER is a
"slot number", a simple integer. The integer is chosen so that the
combination of say "MYEDIT.3" is unique from any other port name. Thus
a text editor could open port "MYEDIT.1", "MYEDIT.2", etc., as required,
re-using slot numbers whenever possible.
Of course, now you have a different problem... if you want to talk to
a text editor, which port name do you use...? Well ARexx scripts usually
don't have to worry because the default host address of an ARexx script
will be set to the correct port by the application that starts it. It's
your own independent scripts that have to worry... In those situations
it may be wise for the application to always open a well-known port for
independent communication.
--
Eric Giguere giguere@csg.UWaterloo.CA
Unlike the cleaning lady, I have to do Windows.nj@magnolia.Berkeley.EDU (Narciso Jaramillo) (03/30/91)
In article <1991Mar27.200758.1432@maytag.waterloo.edu> giguere@csg.uwaterloo.ca (Eric Giguere) writes: > [If you run the same program multiple times, it should create ports > named <APPNAME>.<NUMBER>, where <NUMBER> increases by one for every > new instance of the program.] > Of course, now you have a different problem... if you want to talk to > a text editor, which port name do you use...? Well ARexx scripts usually > don't have to worry because the default host address of an ARexx script > will be set to the correct port by the application that starts it. It's > your own independent scripts that have to worry... In those situations > it may be wise for the application to always open a well-known port for > independent communication. Mg does essentially what you mentioned above--every new invocation of mg creates a different port name. It handles multiple invocation addressing in an interesting way. When you want to talk to an existing mg, you try to address the first possible portname, `mg'. If that exists, you then send it the command `rexx-lock'. If someone else is using that mg, it will fail, and you go on to try the next possible portname, and so on. If no one is using a given copy of mg, `rexx-lock' gives you exclusive control over that mg until you send it the `rexx-unlock' command. nj
m0154@tnc.UUCP (GUY GARNETT) (03/30/91)
The author of that article seemed to be missing several things. Some of the things he says about the Rexx language in the beginning of the article (the comment about 10 being a valid numeric value, while '10' is not comes to mind) are completely off base. Wildstar