Access to one program from another
You can use shared memory (which is an OS-dependant solution), but the design you're talking about makes no sense to me. Maybe step back a bit and give us some context. What is the ultimate goal of this system? What is the input? What is the output? What design constraints are there (and why do they exist)?
He requires 2-way communication, though. I'm not really a command-line guru, so I don't know how you'd do that with pipes.
Addresses are meaningless between different processes.
A unix solution to this problem would be for the first application to write the array to stdout, and the second application to sum the integers arriving on stdin. You would combine them by using the shell to pipe the output from the first program to the second.
He requires 2-way communication, though. I'm not really a command-line guru, so I don't know how you'd do that with pipes.
Why don't you just pass the elements you want to add to the app that is holding the data, and then let the app that is responsible for that data pass the number of elements back to the calling app?
The reality is that sharing data between apps is a REALLY REALLY REALLY bad idea. It can lead to more problems then you can could count. You really want one and only one place that can change data.
The reality is that sharing data between apps is a REALLY REALLY REALLY bad idea. It can lead to more problems then you can could count. You really want one and only one place that can change data.
[quote name='rip-off' timestamp='1313873638' post='4851723']
Addresses are meaningless between different processes.
A unix solution to this problem would be for the first application to write the array to stdout, and the second application to sum the integers arriving on stdin. You would combine them by using the shell to pipe the output from the first program to the second.
He requires 2-way communication, though. I'm not really a command-line guru, so I don't know how you'd do that with pipes.
[/quote]
I was optimising out the redundant write, since the OP never specified any additional reads afterwards...
More seriously, I just failed at reading that post closely enough.Until we know the high level goal the OP has, it is hard to give concrete advice. I still think that any solution which avoids shared memory should be considered, as the potential for bugs is highest with such an approach.
[quote name='Slavik81' timestamp='1313878833' post='4851742']
[quote name='rip-off' timestamp='1313873638' post='4851723']
Addresses are meaningless between different processes.
A unix solution to this problem would be for the first application to write the array to stdout, and the second application to sum the integers arriving on stdin. You would combine them by using the shell to pipe the output from the first program to the second.
He requires 2-way communication, though. I'm not really a command-line guru, so I don't know how you'd do that with pipes.
[/quote]
I was optimising out the redundant write, since the OP never specified any additional reads afterwards...
More seriously, I just failed at reading that post closely enough.Until we know the high level goal the OP has, it is hard to give concrete advice. I still think that any solution which avoids shared memory should be considered, as the potential for bugs is highest with such an approach.
[/quote]
Sockets are a workable solution, and then the two processes don't even have to be on the same machine. (allthough it works best if the communcation can be broken down to messages that can be passed between the processes, for some applications shared memory might very well be the most appropriate solution)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
