NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/sys/amiga/programm/18136

Text File | 1993-01-05 | 6.6 KB | 135 lines

Newsgroups: comp.sys.amiga.programmer
Path: sparky!uunet!paladin.american.edu!gatech!usenet.ins.cwru.edu!agate!spool.mu.edu!umn.edu!csus.edu!netcom.com!jazz
From: [e-mail] (David C. Navas)
Subject: Re: IPC and shared memory
Message-ID: <[e-mail]>
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
References: <[e-mail]> <[e-mail]>
Date: Tue, 5 Jan 1993 01:33:53 GMT
Lines: 124

IPC and shared memory?  My ears are burning!  :)

In article <[e-mail]> [e-mail] (Tomi Ollila) writes:
>In article <[e-mail]> [e-mail] (Jean-Guy Speton) writes:
>
>   I am looking for information on inter-process communications (IPC) and
>   shared memory functions.  Do the Amiga libraries have any functions along

Boy, have you come to the right place.

>   I have a few ideas in mind, but they all
>   seem as if they will become extremely slow and inefficient with more than a
>   few lines.

Depends on what you're trying to do.  If you're trying to send messages with
a character at a time between 10 different processes, yes, you're going to have
a little bit of trouble ;).  If you're doing something easy, like line-IO or
IO streams that are updated on something like a 10ms clock, then no problem.

>I'd imagine that the most efficient results are achieved by using shared
>libray, and returning different base pointer for each OpenLibrary() call.

Ieu, ick :)

>achieve fast IPC. Using Pete Goodeve's ppipc.library along w/ your
>functions makes your code more safe against sudden deaths (without closing
>your library) of some process using your library.

Yes, I use Pete Goodeve's ppipc.library.  That's part of the reason why I
followed-up to this article, instead of the other five on the topic I have
here.

For ANY AND ALL IPC and SHARED MEMORY concerns, I highly recommend at least
looking at shadow.library.  SHADOW V is available via ftp from the physik
mirrors as shadow5.0.lzh.  This archive includes about 500k of Documentation,
so even if the library itself doesn't interest you, you might get some ideas
from reading the Docs and looking at the (rather messy) example programs.

So what is included with SHADOW V?

A quasi-object-oriented scheme (accessed using C and/or assembler) which
allows each method within an object to be run synchronously to the invoking
process, synchronously to a specific process, synchronously to a specific
-named- process [need not be running when class is created], synchronously
to a -class- of processes (processes are objects too!), synchronously to
a process which is created at method invoke time, or....
[breathe]
Each method can be patched at runtime, so that you can change/modify how
methods within classes at at runtime, and (sometimes more importantly)
get copious amounts of debugging data (who calls what methods and when).

A semaphoring system that supports the usual R/W semaphores included with
Exec along with counting semaphores, condition variables, level-triggered
semaphores, etc.  Semaphores need not be pre-created as with Exec
semaphores (ie: there is no user-accessible equivalent to the SignalSemaphore
structure within Exec).

Semaphore-protected access to AVL Tree structures (AVL ~= Binary if you haven't
read about them yet).

Object resource-tracking.  Each object can belong to a specific task, and when
that task quits, the object will be requested to go away.  Each object has
a usecount associated with it and will NOT go away until the usecount
goes to zero.  Several functions provide access to this usecount -- complete
information within the Documentation itself.

WatchedVariable construct which allows other tasks to receive methods when
the variable changes state.  WatchedVariables can exist within objects,
in which case it is possible to "watch" -every- object's variable for
state changes with a single "watcher" object (called Directors in the
Documentation).

Many other things which I'm probably forgetting.

What does it all mean?

It means you can have scads of different programs which can invoke each other's
functions with or WITHOUT a process context switch.  The removal of the
overhead of a context switch is often EXTREMELY important.  Hence shared
libraries.  SHADOW is shared libraries on steroids.  :)

Is all of this true, really?

Well, I'm currently writing a LOT of modules for a data acquisition and
analysis package.  These modules are all subclasses off of a "master module".
Hence, gadget layout routines, state handling (for handling command-line,
WB, Arexx, etc. arguments), event-loop handling, etc. are ALL handled by a
COMPLETELY DIFFERENT program, even though many of these routines happen to
run within the context of the calling module.

For example, the event-loop for each of the created modules is located within
the "master module".  However this METH_PROC_HANDLER method is invoked
synchronously to the caller.  For comparison, the PAUSE methods (if I
remember correctly) run asynchronous to the caller (usually the GUI) and
synchronously to the  "master module";  the GUI methods all run in a
separate GUI process (synchronous to a GUI Process type in many cases); and
the ASL filerequesters all run as auto-invoked processes so that neither
the calling module, nor the calling GUI process are hung waiting for the
ASL requester to return.

The differences between these types of methods are handled by a few flags
within the MethodTag descriptor.  It sounds complicated, and sometimes the
number of data structures (ARGUMENT_TAGs, ATTRIBUTE_TAGs, METHOD_TAGs) can
be annoying, but difficult and code-intensive it is not....

Because the code need not be included with each of the modules, the modules
end up taking around 5k of space each (SAS/C 6.1 w/o optimizer), and then
only because they have to support four separate data types (char, word, float,
double).

Let me know if you don't have ftp access and I'll do my level-best to get a
copy of SHADOW V to you.  If nothing else, you have similar problems to me,
and perhaps the 500k of Docs I've written will spark some of your own thoughts.

BTW -- I know that sending $20 shareware fees (for includes and link-libs)
is expensive for folks overseas -- if anyone overseas is interested, but is
held back by the $20 fee, do not hesitate to contact me through my
[e-mail] account -- I have some thoughts for the first two or three
people, anyway....

--
David Navas                                       [e-mail]
                        [e-mail]
"If it wasn't for the fact that I worked so hard, I'd be a very lazy person."