Path: utzoo!mnetor!uunet!nuchat!peter
From: peter@nuchat.UUCP (Peter da Silva)
Newsgroups: comp.sys.amiga
Subject: Re: Time is of the essence on IPC.
Message-ID: <885@nuchat.UUCP>
Date: 5 Apr 88 03:12:28 GMT
References: <1571@louie.udel.EDU> <353@brambo.UUCP> <1661@louie.udel.EDU> <595@imagine.PAWL.RPI.EDU>
Organization: Public Access - Houston, Tx
Lines: 104
Summary: What do PIPE:s have to do with stdin?

In article <595@imagine.PAWL.RPI.EDU>, jesup@pawl14.pawl.rpi.edu.UUCP writes:
> >But all programs already know how to talk to pipes. The interface is already
> >there. And you don't have to stick with a weird PL/1-like language. You have
> >your choice of any number of weird C-like languages.

> 	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?

*I* don't 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.

> 	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. This would solve my biggest complaint with REXX: you
can't distribute it.

> >> Fifth, the functions in those shared libraries can be made available to any
> >> application that wants to make use of them via the ARexx facility.

> >Just like pipes, except they already have the "PIPE ports".

> 	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 uses plain message ports with an intermediary (can you say performance
> >problems? I knew you could!).
> 
> 	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:

	Program sends message.
	Context switch.
	AREXX gets message.
	AREXX sends reply message.
	AREXX passes message on.
	Context switch.
	Final program gets message.
	Program replies.
	Context switch.
	AREXX gets reply.

And at some point:

	Context switch.
	Original program gets reply from AREXX.

If you don't have an intermediary:

	Program sends message.
	Context switch.
	Receiver gets message.

If it's not a timing message, then:

	Receiver sends reply.
	Context switch.
	Originator gets reply.

Twice as many context switches, best case.

> >And there are free PIPE:s, with source even. I asked "what about an AREXX:",
> >and was met with silence.
> 
> 	Most pipes out there are one-way devices.  (I wrote a bidirectional
> one, but that doesn't matter.  I never released it, and as of 1.3, it'll
> be a moot point.)  Pipes don't provide an interactive envirionment.  Why do
> you think Unix people invented (adopted) sockets and shared memory?

Have you looked at System-V named pipes (FIFOs)?

> 	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.
Close fh.

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

> 	Pipes are useful things, but they are sorely lacking for many
> applications.

True, but for a good many applications they're just fine.

-- 
-- a clone of Peter (have you hugged your wolf today) da Silva  `-_-'
-- normally  ...!hoptoad!academ!uhnix1!sugar!peter                U
-- Disclaimer: These aren't mere opinions... these are *values*.