Thanks Waverly,  

for a stimulating answer concerning 
sharing handles to segments in system RAM among 
sister applications.

My comments:

(1)
 > If the block of memory is relatively small I would stick
 > with the system heap.

Really?  Why not share BIG blocks?  Is is true that each
application resides in one such segment reserved by the OS!?  I
have observed that smart applications that have transient BIG
RAM requirements do use system RAM.

It seems System heap zone(s?) the Finder shows in the Apple
menu is wonderfully elastic; the following
trivial FB2 demo

H&=FN NEWHANDLE _sys(&800000)
IF H&=0 THEN BEEP: END
P&=FN HLOCK (H&)
INPUT JK$
X%=FN HUNLOCK (H&)
X%=FN DISPOSHANDLE(H&)
END

grabs 8 Meg, reliably on my ancient FX (OS755); and other apps
I use do better squeezing until <1 Meg of RAM is globally free
(perhaps by using GROWZONE and the like).

(2)
You seem to think that if the sister app who created the handle
quits without releasing the handle then the handle will be
still there and valid.  You must be right; I'll have to
recheck.  It is certainly true that the Sys never gets back the
the RAM allocated. Maybe, contrary to my first impressions any
app can fool around with any system heap handle as soon as it
knows the handle (ie the master pointer).  Anyone have the
lowdown on this?

That would be a nice friendly neighborhood policy.
(But if is is for real, I'm sure it won't last:-/)

(3)
 > I find the biggest probem is signaling the
 > applications to stop accessing the shared block.

Why not have all users verify handle validity before
reading or writing data to the shared block, say by 
one of these:

FN GETHANDLESIZE [= IM's GETHSIZE] 
FN HGETSTATE [= IM's GETHSTATE]
FN RECOVERHANDLE

Or better, have them check a validity signature within the
block (to be erased when the handle becomes off-bounds).

 > This assumes both programs are not synchronously synergistic.
 > If they are synchronous then signaling is not a problem.

What about signaling invalidity a known number of ticks before
really invalidating.  Then a validity check is OK for a known
period. And it can be double checked on concluding the
read/write operation. Yes, this is a bit of a hassle, but not
exceptional.

(4)
Concerning subterfuges for passing around the shared handle,
you mention some intriguing possibilities:

(a) A custom gestalt 
(b) An init
(c) Appleevents
(d) Custom low level events
(e) PPC communications (I'm not sure this manager still exists)
(f) A file.

You say something about (c).  The possibility (d) attracts me;
could you say a bit more about it?

Cheers

Larry S

PS. Anyone else have experience in this area?