From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4b12bc9a1cc5c6c3 X-Google-Attributes: gid103376,public From: "Condic, Marin D." Subject: Re: Spawning a subprocess and communicating with it. Date: 1998/10/12 Message-ID: #1/1 X-Deja-AN: 400246573 Sender: Ada programming language Comments: To: "dale@cs.rmit.edu.au" Content-Type: text/plain MIME-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-10-12T00:00:00+00:00 List-Id: The model you suggest sounds interesting. I don't know much about what compiler options you'd have to use (or other linkage issues that might be involved) to get this sort of thing to work, but it doesn't sound particularly hard. Maybe you have a "Hello World" of distributed processing you could share? While the distributed issue could certainly be useful in other contexts, I don't think it would suit my current problem. Imagine my embedded control software running in its own little box and periodically looking at a MilStd1553 bus for a message from the monitor program. It receives a message, collects up some data and blips it back down the wire. I can't change that software because it already exists in lots of boxes. What I'd like to do is run a variation of that software on a workstation with no "structural" changes - just a thin layer of code that says "Instead of getting your messages from a MilStd1553 bus, you're going to be getting them from this OS supplied pipe - otherwise, they look identical and the protocol is the same." The same situation would exist for the monitor program - either it uses the MilStd1553 to talk to the embedded code in the "real" machine, or it uses a pipe to communicate with a variation of the software compiled for the workstation. (Initially a Sun/Unix box, but soon to be appearing in a WinNT box as well.) There may be some way of visualizing this all as RPCs, but it sounds like I'd be building some layer of complexity I don't need if all I want to do is change the transport mechanism for a message passing system that is already in place. BTW: You wouldn't happen to know how to make the CreateProcess system call work on WinNT using Win32ada? I've been fighting it for days and keep loosing. Maybe there's some secret handshake for getting system calls to work with GNAT on the PC??? ;-) MDC > ---------- > From: dale@cs.rmit.edu.au[SMTP:dale@cs.rmit.edu.au] > Sent: Sunday, October 11, 1998 7:22 AM > To: Condic, Marin D. > Subject: Re: Spawning a subprocess and communicating with it. > > In article , > "Condic, Marin D." wrote: > > hello Marin, > > I've (and my first year students) have used the DSA, and found it quite > easy to use. The model it presents is of one large Ada program that is run > on separate machines. > > We managed to have a client server model for a chat room. Students would > write simple programs that called on the services of a package (who is in > the room with me, what doors are there from this room, say something to > the people in the room etc). The students programs were then compiled > using gnatdist, which translated the conventional procedure calls into RPC > stubs. The package would receive the calls (you didn't have to do anything > special - the DSA details were all hidden from you), and service them as > any other call to the package would have been. > > All in all a very easy way to run programs. If you can imagine your system > as a large Ada program consisting of independent Ada tasks, then this > model is a very easy way to approach this sort of problem. > > Dale >