Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cbmvax!bagate!dsinc!unix.cis.pitt.edu!zaphod.mps.ohio-state.edu!swrinde!kent
From: kent@swrinde.nde.swri.edu (Kent D. Polk)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Inter process communication
Message-ID: <1899@swrinde.nde.swri.edu>
Date: 15 Mar 91 15:33:02 GMT
References: <11854@pasteur.Berkeley.EDU> <1808@swrinde.nde.swri.edu> <12004@pasteur.Berkeley.EDU>
Sender: news@swrinde.nde.swri.edu
Organization: Southwest Research Institute, San Antonio, Texas
Lines: 125

In article <12004@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU writes:
>
>IN particular, I think you have the following (please forgive me if I get the
>	PPIPC calls named incorrectly, it's been to long...):
>
>
>	ServerList --> port1 --> port2 --> port3 --> port4 --->||
>
>   Now when you go to send a message you do a PutIPCMessage(port1, msg),
>and if it succeeds, you await a reply, if not you try port2.  When you
>receive a reply you try port2.  This process continues.

Actually I make use of a special message id which by design does not
expect a reply. All others do. The non-replying message is passed to
the succ message port as in your example below.

>The ReplyPort problem I have is this:
>
>	Let's say that when you send a message off to port1, you *don't*
>	await your response, and send off to port2, port3 and port4.  Now
>	you shut yourself down.
>
>	What do you do when with those messages when the ReplyMsg (really,
>	the PutIPCMsg(msg->ipc_Msg.mn_ReplyPort, msg) ) fails?  Specifically,
>	when TaskX tries to reply, the message *bounces* off the shut port.
>	Do you delete the message?  What if the message has pointers in it --
>	do you de-allocate those regions too?  How?
>

I provide a solution to the problem by limiting the possibilities.
Unfortunately, limiting the possibilities also limits functionality,
but... I'm working on it. I handle the problem as such:

  Manager (Task launcher/manager and semaphore messageport list setter-upper:^)

   > Sampler --> port1 --> port2 --> port3 --> port4 --->|
   |                                                     |
   ------------------------------------------------------ 

In this mechanism, the sampler allocates a 'stack' of "BELT" messages,
and attaches a data event buffer ptr with each as they get sent out.
These messages have a "BELT" message id. When the receiver gets this
message, and recognizes it to be a "BELT" id, it nulls the ReplyPort
ptr, and calls relay_msg():

/******************************/
int relay_msg(msg)
struct IPCMessage *msg;
{
   int i;
   int didit = FALSE;

   if (my_node) {
      for (i=0;i<TIMES && !didit; i++) {
         ObtainSemaphore(sema);
         if (PutIPCMsg(my_node->succ_port, msg)) didit = TRUE;
         ReleaseSemaphore(sema);
         if (!didit) Delay(10);			/* "Drive friendly" */
      }
      if (!didit) mputs("Error sending message");
   }
   return (didit);
}

Note that the PutIPCMsg() has never failed the first time (except when I forced
it for testing purposes), even in the midst of message ports being inserted and
deleted because of the Semaphore controlled list.

Now, my solution to the problem is that the Sampler (which allocates
the BELT message stack) doesn't shut down until ALL BELT messages have
been returned. Note that this is possible since the sampler is the
originator of all BELT messages. BTW, the messages are allowed to come
in in any order as the 'stack' is an array of messages pointers. When a
new message comes in, it's address simply gets assigned to the array
index I am pushing back on the stack. In actuality, I don't believe
they have ever gotten out of order (except when I was developing this
stuff & lost a few messages here and there).

Actually there is one more message that is passed this way - an "INIT"
message, which tells all filters to reconfigure for another sampler.

Back to ReplyPort being nulled: I read in the RKM's that if the
RepoyPort is null, no message is sent. I use this to provide a simple
mechanism without exceptions in my message handler stuff -> Normal
messages get replyed to, BELT and INIT messages get relayed.

Now, back to your question:

>If you have developed a task-independent solution both Pete and myself would
>be rather interested...  (of course, that's short of counting the number of
>messages actually sent out and awaiting their reply, which under certain
>circumstances might be quite difficult...)

:^)

Now, can I join in on the discussion? I have some ideas... some things I
want to do - like expanding (rewriting) to provide for several new projects.
Specifically in this order:

- Getting rid of some of the limitations (Making better use of PPIPC capabilities)
- Providing a graphic environment for this stuff,
- Writing a graphic "logic simulator"
- Expanding & combining the logic simulator with the data-acq. stuff to
provide a complete data-acq. hardware simulator.

Ambitious, aren't I? (Wish I could do this for a living)

I was talking with Pete about this, but he abandoned me so he could go
play with his Amiga. Imagine that! (Pete; a sense of humor now...)

----------------------------------------------------------------------
This is while I try to work on that gpib.device. BTW, can anyone point
me to source or at least a complete outline for writing a multi-unit
device - as in something like scsi.device? I have started on the
design, but would like a better idea of how Amiga devices like this
should be set up - i.e. I'm starting from a Unix background and trying
to convert my ideas from there to the Amiga way of doing this stuff.
There are a number of ways of handling device commands as well as the
controller (local) commands themselves. Help would be very much
appreciated.

Thanks,
Kent Polk: Southwest Research Institute (512) 522-2882
Internet : kent@swrinde.nde.swri.edu
UUCP     : $ {cs.utexas.edu, gatech!petro, sun!texsun}!swrinde!kent