Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!cornell!batcomputer!itsgw!imagine!pawl21.pawl.rpi.edu!jesup
From: jesup@pawl21.pawl.rpi.edu (Randell E. Jesup)
Newsgroups: comp.sys.amiga
Subject: Re: Time is of the essence on IPC.
Message-ID: <627@imagine.PAWL.RPI.EDU>
Date: 7 Apr 88 08:20:26 GMT
References: <1571@louie.udel.EDU> <353@brambo.UUCP> <1661@louie.udel.EDU> <595@imagine.PAWL.RPI.EDU> <885@nuchat.UUCP>
Sender: news@imagine.PAWL.RPI.EDU
Reply-To: beowulf!lunge!jesup@stienmetz.UUCP
Organization: RPI Public Access Workstation Lab - Troy, NY
Lines: 81

In article <885@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes:
>In article <595@imagine.PAWL.RPI.EDU>, jesup@pawl14.pawl.rpi.edu.UUCP writes:
>> 	If you mean, "all programs invoked from CLI could theoretically read
>> data from stdin (Input()), and send data to stdout (Output())", OK.  But
>> I suspect most programs (other than Unix filter/utility ports) ignore attempts
>> to pass commands via stdin.  Ever seen DPaint care about stdin?

>In dPaint: select Save, and specify "PIPE:butcher". In butcher: select Load,
>and specify "PIPE:butcher". The programs talk to each other, pause when the
>PIPE: is full, and so on. Voila. IPC.

	Data transfer, yes.  Not what I would call IPC, however.  You can't
pass commands, it's an essentially one-way connection, and requires the user
to do the work, etc, etc.

>> 	If you don't like the Rexx language, write your own program that uses
>> ARexx ports to control other programs in place of ARexx itself.
>Good idea. Something like this should be freely available to ship with
>everyone who wants to use REXX ports but doesn't want all their customers
>to have to buy REXX.

	So what's stopping you? :-)

>> 	NO. Wrong.  One cannot call code in a pipe.  ARexx libraries are
>> exec libraries that are accessed by calling them directly, like any other
>> library.
>Oops. You changed context on me, and I missed it. Explain how these shared
>libraries work (programmer interface, anyway).

	ARexx is implemented as a library of routines, any of which you can
call the way you would other libraries.  You can add external libraries of
functions, which are callable by ARexx, and any other program.  This allows
ARexx macros to access a programs code, for example, without having the
overhead of task switching, message passing, and command parsing.  For
example, a graphics program might put most of it's low-level primitives into
a library, which ARexx (and others) could then call directly, instead of
having to request the graphics program to do the operation and return the
result.
	The only real addition to a standard library is a 'query' entrypoint
in the library that matches names of routines to specific library entries.

>> 	You have a better way to pass a message?  Remember, messages aren't
>> copied, to send a message only requires a small number of instructions.
>
>It takes extra context switches:
	[describes ARexx just being a switch between two tasks]
>Twice as many context switches, best case.

	This is not what ARexx was designed for.  If you don't want to use
the macro language, why would you pass messages through it?  ARexx is NOT
a message-forwarder (though it could do it if you wanted it to).  It is a
programming language made for providing macros for other programs.  It is also
fairly powerful standalone.
	Now, if ARexx was performing some filtering operation, then having
the messages run through ARexx makes sense.  For your case (Arexx just passing
them on), the programs could just send messages to each others Rexx ports.

>> 	What would you expect this hypothetical "Arexx:" to do, anyway??
>> I'm not suprised you got silence, as I can't figure out what you seem to
>> be asking for.
>
>Open AREXX:function-name, giving a file handle.
>Send data to it, using DOS calls.
>Get replies back.

	How?  Reads, I assume?

>Close fh.
>
>SO THAT PROGRAMS THAT DON'T KNOW FROM AREXX CAN USE IT.

	How?  (Reads??)  I suppose this would work, though you lose a lot
of the functionality.  What does this get you that a pipe doesn't for programs
that aren't specifically coded to take advantage of this?  (If they could be
so coded, might as well code in an ARexx port instead, and get more
functionality.)

     //	Randell Jesup			      Lunge Software Development
    //	Dedicated Amiga Programmer            13 Frear Ave, Troy, NY 12180
 \\//	beowulf!lunge!jesup@steinmetz.UUCP    (518) 272-2942
  \/    (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup
(-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)