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.9 required=5.0 tests=BAYES_00 autolearn=ham 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/13 Message-ID: X-Deja-AN: 400647545 Sender: Ada programming language Comments: cc: "Moran, Tom" Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-10-13T00:00:00+00:00 List-Id: Tom Moran writes: >This sounds like you could have your main Ada program start a task >which would call the main procedure in the other program, and then >they could trade information via a (protected) buffer or something. That would work if I could live with a monolithic program. The problem is that the two units are difficult to intertwine. On the one side, you have a Monitor program which wants (normally) to communicate with an embedded computer via a 1553 bus. I want to modify it to use either a 1553 bus or an OS Pipe so that it can talk to a "simulated" embedded computer. On the other side, I've got software which would normally run in the embedded computer that I want to wrap with some "glue" software such that it can be compiled and run on a Workstation or PC. The "glue" simply wants to hide the 1553 bus behind an OS Pipe so that, hopefully with minimal change to the embedded software, it can behave just as it does in its embedded box - just getting the messages via a different transport. I don't think it would be a good idea to be trying to create versions of each software product which have to be compiled and linked together in order to communicate. That could begin to hurt a lot, not to mention start structurally changing things so that you can't be sure of similar behavior to the "real" software. > But other messages in this thread suggest that the 'subprogram' may >in fact be running on another machine (in which case as noted the >Distributed Annex would be appropriate) but it is already in existence >and cannot be changed and does not use the Distributed Annex for its >communication. That implies the programs need to talk via the OS. >Unless the existing program(s) use some OS communication method that >is transparent as to whether one, or more, CPUs are involved, it sure >sounds like you are going to have to write some glue code to abstract >away the CPU count. So this is really a language independent OS >question. > Or did I miss something? I don't think the Distributed Annex is appropriate - although somebody might suggest a model which would allow things to work with minimal fuss. The embedded software is already in existence, but to run it on the workstation would require some wrapper software to hide the lack of physical devices. (mostly, at this juncture, the 1553 bus) So I'm not totally against any modification to the embedded side - I'd just like to minimize it. My understanding of the Distributed Annex is that it gives you two mechanisms for passing messages between separate processes. One is some form of shared memory. The other is a Remote Procedure Call with parameters. Neither of these lines up really well with what the software does now - transmit/receive messages across a wire. Whereas an OS Pipe is nearly an identical mechanism. To use a shared buffer, I'd have to drastically change the way messages are passed between the monitor and the embedded software such that I'll really end up with two distinct products which may not behave in exactly identical ways. To use an RPC, I'd have to (on the transmit side) do something to change the bundling up & sending of bytes into the passing of parameters to a remote procedure. On the receiving side, instead of responding asynchronously to the arrival of a message, I've got a procedure which gets called that then has to take its parameter and do something to make it look like a message arrival. And then there's the problem that *both* pieces of software are going to transmit and receive and I'm not sure how that figures into an RPC kind of model. So I'm thinking that the Distributed Annex, while interesting for a whole lot of reasons, may not be the best fit to this problem. I've seen some possible methods of firing up child processes from both WinNT and Unix. I've also seen some calls for creating the pipes between the processes. I think that some version of this is probably the answer I need. My problem at this point is that I can't quite get the behavior I want from the Unix side (my ignorance, no doubt) and I can't get the WinNT calls to work at all. (Must be doing something wrong! ;-) The GNAT.OS_Lib package seems to provide some semi-standard ways of creating the child process, (which is good if I've got to support both platforms) but on either the Unix or WinNT side, it doesn't seem to create a separate "window" for the child process. (Maybe that's *more* OS calls?) It is also not clear if it is possible to use the GNAT.OS_Lib to create a pipeline between the two processes. So I'm still doing research and hammering away at different trial-and-error programs to see if I can get something to work at the "Hello World" level. If you've got any examples or suggestions, I'm listening. Thanks MDC Marin D. Condic Real Time & Embedded Systems United Technologies, Pratt & Whitney Government Engines & Space Propulsion M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 Ph: 561.796.8997 Fx: 561.796.4669 "Today is the first day of the rest of your solitary, poor, nasty, brutish, and short existence on this planet" -- "Life In Hell"