Can we stop and .exe from anthoer .exe
-
Hi , Is it possible to stop a running .exe and resume it later . After googling I came to know that every .exe is isolated from any other .exe. I am creating an application which will act like a 'BreakPoint setter' for second .exe . Is it possible to stop execution of exe and its threads from another .exe. Thanks
-
Hi , Is it possible to stop a running .exe and resume it later . After googling I came to know that every .exe is isolated from any other .exe. I am creating an application which will act like a 'BreakPoint setter' for second .exe . Is it possible to stop execution of exe and its threads from another .exe. Thanks
Hi, I am not sure this is possible, but If you do so, I think there will be a possibility for deadlock. Nitheesh George http://www.simpletools.co.in
-
Hi, I am not sure this is possible, but If you do so, I think there will be a possibility for deadlock. Nitheesh George http://www.simpletools.co.in
Both the .exe file will be created under one parent application. One is a UI process and another is worker exe UI will try to add some break point and on the 'Click' event the another .exe will stop/resume its execution. So I cannt see any possiblity for deadlock. Correct me if I am not clear to explain
-
Both the .exe file will be created under one parent application. One is a UI process and another is worker exe UI will try to add some break point and on the 'Click' event the another .exe will stop/resume its execution. So I cannt see any possiblity for deadlock. Correct me if I am not clear to explain
pandit84 wrote:
One is a UI process and another is worker exe
Why a worker executable? What's wrong with a worker thread? That way, you consume less resources AND can get the job to be done faster! Just use a worker thread, and one of the many thread synchronisation mechanisms like Critical section, mutex, etc. It could be as simple as a volatile variable, or could be as complex as a semaphore or having to use a pool of threads. Read up on thread synchronization, and use whichever synchronisation mechanism that suits your need.
"Real men drive manual transmission" - Rajesh.
-
Both the .exe file will be created under one parent application. One is a UI process and another is worker exe UI will try to add some break point and on the 'Click' event the another .exe will stop/resume its execution. So I cannt see any possiblity for deadlock. Correct me if I am not clear to explain
I totally agree with Rajesh, and I would like to point you to this great article[^]. It will really help you understand how to work with threads.
Cédric Moonen Software developer
Charting control [v3.0] OpenGL game tutorial in C++ -
Both the .exe file will be created under one parent application. One is a UI process and another is worker exe UI will try to add some break point and on the 'Click' event the another .exe will stop/resume its execution. So I cannt see any possiblity for deadlock. Correct me if I am not clear to explain
You need some form of Inter-Process Communication to do that, see, for instance, Interprocess Communications[^] at
MSDN. :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
You need some form of Inter-Process Communication to do that, see, for instance, Interprocess Communications[^] at
MSDN. :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]The another .exe which is my worker exe will be running on a third party RTOS . Using synchronization it is possible within Win32 and RTOS process. My requirement docs says to stop a RTOS process from UI with a button click and resume it again with same button click (like a toggle) . Things will get more complex if synchronization is used because I am having ~32 threads on RTOS running. ... Thanks a lot for your nice reply
-
The another .exe which is my worker exe will be running on a third party RTOS . Using synchronization it is possible within Win32 and RTOS process. My requirement docs says to stop a RTOS process from UI with a button click and resume it again with same button click (like a toggle) . Things will get more complex if synchronization is used because I am having ~32 threads on RTOS running. ... Thanks a lot for your nice reply
pandit84 wrote:
The another .exe which is my worker exe will be running on a third party RTOS . Using synchronization it is possible within Win32 and RTOS process. My requirement docs says to stop a RTOS process from UI with a button click and resume it again with same button click (like a toggle) . Things will get more complex if synchronization is used because I am having ~32 threads on RTOS running
What RTOS?! And 32 Threads running on an embedded OS? :~ You did not give enough information in your first post. See How to ask a question[^], and edit your question to include all relevant information for someone to give you an appropriate response that may be of help.
"Real men drive manual transmission" - Rajesh.
-
pandit84 wrote:
The another .exe which is my worker exe will be running on a third party RTOS . Using synchronization it is possible within Win32 and RTOS process. My requirement docs says to stop a RTOS process from UI with a button click and resume it again with same button click (like a toggle) . Things will get more complex if synchronization is used because I am having ~32 threads on RTOS running
What RTOS?! And 32 Threads running on an embedded OS? :~ You did not give enough information in your first post. See How to ask a question[^], and edit your question to include all relevant information for someone to give you an appropriate response that may be of help.
"Real men drive manual transmission" - Rajesh.
-
I appologies. I thought it like a normal programming scenerio. My application is actually a industrial software UI application with host 32 threads for a motion controller like a industrial robotics arms.
So, give the following information:
- Which operating system does your code run on? [Note: This particular board deals primarily with Windows, and may be flavours of UNIX. Other platforms can be supported as long as you're not doing anything propreitary to the OS, because people just may not know about it].
- Are all the 32 threads are running in the context of the same process? If so, just use a thread synchronisation mechanism.
- And what is this "other exe" you're talking about?
Please read the points mentioned in the link I gave you in my earlier reply, and include ALL relevant information if you want someone to help you.
"Real men drive manual transmission" - Rajesh.
-
So, give the following information:
- Which operating system does your code run on? [Note: This particular board deals primarily with Windows, and may be flavours of UNIX. Other platforms can be supported as long as you're not doing anything propreitary to the OS, because people just may not know about it].
- Are all the 32 threads are running in the context of the same process? If so, just use a thread synchronisation mechanism.
- And what is this "other exe" you're talking about?
Please read the points mentioned in the link I gave you in my earlier reply, and include ALL relevant information if you want someone to help you.
"Real men drive manual transmission" - Rajesh.
1. User interface is a Win32 process which communicates with worker layer (running on RTX - RTOS) , using shared memory. UI will be running on windows OS and Worker Layer exe will be running on Interval Zero RTX (Ver 2011). Worker on RTX RTOS will further communicating with hardware ( Industrial firmware components ) to control 32 motion controller devices. > 32 Threads are in same context i.e. on worker layer side. >"Other Exe" is nothing but RTX executable i.e worker exe. Again I would like to say a big "THANKS"
-
1. User interface is a Win32 process which communicates with worker layer (running on RTX - RTOS) , using shared memory. UI will be running on windows OS and Worker Layer exe will be running on Interval Zero RTX (Ver 2011). Worker on RTX RTOS will further communicating with hardware ( Industrial firmware components ) to control 32 motion controller devices. > 32 Threads are in same context i.e. on worker layer side. >"Other Exe" is nothing but RTX executable i.e worker exe. Again I would like to say a big "THANKS"
What I would do is create a program
'work_cmd.exe'for your target platform that only handles the communication with your Win32 UI and nothing else. Your current worker.exe then should be demoted to a thread, and will be spawned from'work_cmd.exe'. It will still be responsible for spawning the 32 sub-threads, but it needs explicit functions for the purpose of suspending or resuming those threads. Your'work_cmd.exe'can then just tell your worker thread to suspend it's dependend threads, and, upon completion, suspend the worker thread itself. To resume, it resumes your worker thread, and then tells it to resume its 'sub-threads'. Note that my suggestion takes two commands to suspend or resume your threads, as'work_cmd.exe'doesn't know about the additional threads and delegates their management to your worker thread. This assumes that the additional threads will not automatically be suspended with their parent. Maybe it's possible to spawn them in a way that forces them to be suspended whenever their parent is, but that might depend on your RTOS. (I'm not familiar with RTX) Note, also, that'work_cmd.exe'will have to keep running and listening for UI commands. -
1. User interface is a Win32 process which communicates with worker layer (running on RTX - RTOS) , using shared memory. UI will be running on windows OS and Worker Layer exe will be running on Interval Zero RTX (Ver 2011). Worker on RTX RTOS will further communicating with hardware ( Industrial firmware components ) to control 32 motion controller devices. > 32 Threads are in same context i.e. on worker layer side. >"Other Exe" is nothing but RTX executable i.e worker exe. Again I would like to say a big "THANKS"
So the unique possibility for your GUI to pause/resume the worker thread is by setting a value into the shared memory (and the worker application must poll this value constantly.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Hi , Is it possible to stop a running .exe and resume it later . After googling I came to know that every .exe is isolated from any other .exe. I am creating an application which will act like a 'BreakPoint setter' for second .exe . Is it possible to stop execution of exe and its threads from another .exe. Thanks
If the other application is running as a Windows service, then the "monitor" application can send a SCM pause command to the Windows service.
-
If the other application is running as a Windows service, then the "monitor" application can send a SCM pause command to the Windows service.