0

I have the following scenario, I have two programs running one in the background and one in front. The back program is doing some stuff for the front program. once the back program has done the necessary configuration it signals that it has finished the backup support for first program and the now the front program needs to be killed and the back program will take control of first program.

Help is highly how would I accomplish this scenario in Linux. Any direction or hint is highly appreciated.

2
  • 3
    If the front program is killed, then there is nothing for the back program to take control of? What are you actually trying to achieve, how do these two programs communicate, and are they own-code (i.e. can you change their behaviour as needed to meet this requirement?) – Paul_Pedant Oct 17 '20 at 20:15
  • Hi @Paul_Pedant, I have program running in the front and from the front program back program is initiated and as soon as back program finishes, it signals the first program and and then the back program starts take control of first program, and first program is killed. – emaan daavis Oct 18 '20 at 10:42
0

It is difficult to understand the requirement as specified, so first I will try to show where additional explanation may be needed.

You have tagged this post with "Migration", so I assume these programs already exist and are known to work on some non-Linux architecture. The concepts of inter-process communication and signalling are fairly universal, but stating the architecture and OS the programs presently run on would be very helpful.

I also see the tag "multithreading" although the text only mentions two distinct processes. Does either of the programs actually multithread?

I initially considered that "front" and "back" related to a foreground and background process started by a shell (also tagged). But that is not a true relationship between the processes themselves, only their relationship with their launching mechanism.

I believe you are referring to a "front-end" program that provides a GUI for the entry of parameters, and once these are passed to the "back-end" program it proceeds autonomously. It is also possible that the front-end may need to only be suspended, until the GUI can be used again to provide feedback or results.

A key question is the communication of parameters between the two programs. The methods I am aware of include: shared memory; piped streams (as unnamed pipes, named pipes, or sockets); and shared files. Signals are only suitable for events, not for data flows. The existing mechanism has to be understood so we can proceed.

It is not possible for a program to "take control" of another. There may exist a parent-child relationship (and either your front-end or back-end could be the parent), but the relationship cannot be reversed. The function of the parent is to pre-arrange the communication between parent and child: alternatively, the parent may launch two children (siblings) that can communicate with each other.

Either parent or child can signal the other, and in fact each signal can kill the other process. It is more usual to end the relationship by closing the channels of communication between them, which gives the ending program the capability of a tidy closedown.

If you already have these programs, it would be very helpful to know exactly how they interact at present, so that the closest match of Linux features can be recommended. There is no purpose in my suggesting a model that requires major changes in the existing code, when another approach could be a far better fit.

It is almost certain that Linux can provide the necessary environment for these programs to co-operate. The issue is that we still know nothing about the existing mechanisms that would need to be emulated, or indeed whether you have access to the source of the programs, and what language they are written in.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.