Re: Spawning a subprocess and communicating with it.

["Condic, Marin D." <condicma@PWFL.COM>]

Tom Moran <tmoran@BIX.COM> 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"