Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!oliveb!amiga!cbmvax!ulowell!hawes
From: hawes@dino.ulowell.edu (Bill Hawes)
Newsgroups: comp.sys.amiga
Subject: Re: Time is of the essence on IPC.
Message-ID: <1954@dino.ulowell.edu>
Date: 2 Apr 88 02:15:49 GMT
References: <1571@louie.udel.EDU> <353@brambo.UUCP> <1661@louie.udel.EDU> <25552@amdahl.uts.amdahl.com> <872@nuchat.UUCP>
Reply-To: hawes@dino.ulowell.edu (Bill Hawes)
Organization: University of Lowell Productivity Center, Lowell MA.
Lines: 88

In his article peter@nuchat.UUCP (Peter da Silva) touts the use of pipes 
as an IPC mechanism ...

Hey Peter, I do pipes, too ...

As others have stated, just because you use one method for IPC doesn't 
preclude using others as well.  In the WSHell you get piping support in 
the pure UNIX tradition of
  3> program1 args | program2 args | ... ProgramN args
yielding N concurrently-running processes with the expected input-output
connections.  It uses the pipe handler built into ConMan, which ensures
multitasking-safe piping support by obtaining both pipe filehandles
simultaneously (using a private packet called ACTION_DOUBLE.)

Under WShell, you can mix-and-match executable programs with REXX macros 
in a piping system, so this allows you to use the REXX tracing/debugging 
facilities to monitor the pipe.  Ever single-stepped a system of piped 
programs?

As for a few specific comments:

>Bingo. AREXX is a script program that happens to include an IPC facility.

Communicating with external programs is hardly incidental to REXX.
Of the three types of executable statements in the language --- assignments,
instructions, and commands --- commands are reserved for communications
with external programs.  The semantics of a command are determined entirely
by the external host.

While it's true that in mainframe implementations of REXX these commands 
are not strictly "IPC", since there's no concept of a process (or even 
device-independent I/O), the Amiga implementation depends heavily on the 
system message-passing primitives.  


>AREXX uses plain message ports with an intermediary (can you say 
>performance problems? I knew you could!).

The AREXX server is in the loop only to launch the macro program; it spawns
a new process and forwards your invocation message as the startup.  After 
that, the REXX program talks directly with your application, or any other
AREXX host, or its STDIN and STDOUT streams, or anything else that you want
it to do.  And is that "intermediary" spelled as p-i-p-e-h-a-n-d-l-e-r?
If it makes you more comfortable, you can think of a REXX program as an
intelligent piping filter.


>But all programs already know how to talk to pipes ...

Don't I wish!  Most of the AmigaDOS commands are at best marginally useful
as filters.  I'm getting comments back from WShell customers (many of whom 
haven't been exposed to piping before) asking for more examples of its uses.
Maybe some of you with drawers full of filter programs could select your
favorites and send them to me?


>And there are free PIPE:s, with source even.

Shucks, I guess not all the best things in life are free :-)  
I tried to price AREXX low enough so that people wouldn't hesitate to try 
it, and ignored advice to price it higher (from people who know lots more
about marketing than I do.)  If the price really is an obstacle, maybe we 
could take up a collection here to buy you a copy.
I'll chip in the first $10.

>I asked "what about an AREXX:", and was met with silence.

Echoing Randell Jesup, I ask: what is an AREXX: device?  If you can provide
a useful spec, I'll consider writing it.  Note that it would be trivial
to define a DOS handler to invoke AREXX, but what would you gain?  If you
called it synchronously, you'd lose the ability to have the REXX program
send commands to your application (since it would be WAITing the reply.)
And if you intend to use it asynchronously, what's wrong with the present
message-passing interface?  Could you talk effectively to Intuition through 
an INTUITION: handler?


I hope that you can be persuaded to give AREXX a try.  From what you've
shown of Browser, it sounds like adding an AREXX interface to it would 
be MIT**, and you'd end up with a fully-programmable file browser/launcher/
whatever, and you'd be able to talk to the other AREXX host programs.

** == Most Incredibly Trivial

A side note>>> Apologies to any who may have tried to EMail me; I appear
to be unmailable, though not unmalleable.  My BIX and PLINK ids are WHAWES, 
and USnail is currently working rather well -- 2 days from the West coast.

   -- Bill Hawes