Interprocess communication in C without pipes or disk
-
A mate just called and was picking my brain about how best to handle inter-process communication in plain C. His requirement is he has a monitor app watching a process and if that process goes dark he restarts it. However, sometimes that child app is actually still functioning - it's just a little busy and doesn't respond to the monitor's pings. What he'd like is a way to have the child process increment a counter that the monitor can watch. If the counter is incrementing then it's all good and it'll back off. If the child goes dark and the counter stops incrementing then it's time to kick it. Any thoughts on how best to accomplish this in the simplest, most member efficient way that doesn't require the installation of something like MSMQ? Oh, and the kicker: it needs to support Windows XP and Windows 2003. There's a lot of those installs still out there...
cheers Chris Maunder
-
A mate just called and was picking my brain about how best to handle inter-process communication in plain C. His requirement is he has a monitor app watching a process and if that process goes dark he restarts it. However, sometimes that child app is actually still functioning - it's just a little busy and doesn't respond to the monitor's pings. What he'd like is a way to have the child process increment a counter that the monitor can watch. If the counter is incrementing then it's all good and it'll back off. If the child goes dark and the counter stops incrementing then it's time to kick it. Any thoughts on how best to accomplish this in the simplest, most member efficient way that doesn't require the installation of something like MSMQ? Oh, and the kicker: it needs to support Windows XP and Windows 2003. There's a lot of those installs still out there...
cheers Chris Maunder
Try putting something like this into a dll:
#pragma section("SharedSection",read,write,shared)
__declspec(allocate("SharedSection")) int counter = 0;a shared instance of counter should then be available to all instances running on the same computer that links to the dll ... [#pragma section documentation](https://msdn.microsoft.com/en-us/library/50bewfwa.aspx) Best regards Espen Harlinn
Espen Harlinn Chief Architect - Powel AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
-
A mate just called and was picking my brain about how best to handle inter-process communication in plain C. His requirement is he has a monitor app watching a process and if that process goes dark he restarts it. However, sometimes that child app is actually still functioning - it's just a little busy and doesn't respond to the monitor's pings. What he'd like is a way to have the child process increment a counter that the monitor can watch. If the counter is incrementing then it's all good and it'll back off. If the child goes dark and the counter stops incrementing then it's time to kick it. Any thoughts on how best to accomplish this in the simplest, most member efficient way that doesn't require the installation of something like MSMQ? Oh, and the kicker: it needs to support Windows XP and Windows 2003. There's a lot of those installs still out there...
cheers Chris Maunder
Just make a WM_USER + X message and the child window handles the WM_USER + X message to return it's status. If it's dead you wont get a response or you get a bad status you don't expect then kill it. Windows makes the window not responding decision the same way (just with its message range) :-) WM_USER (Windows)[^]
Message numbers in the third range (0x8000 through 0xBFFF) are available for applications to use as private messages. Messages in this range do not conflict with system messages.
In vino veritas
-
Try putting something like this into a dll:
#pragma section("SharedSection",read,write,shared)
__declspec(allocate("SharedSection")) int counter = 0;a shared instance of counter should then be available to all instances running on the same computer that links to the dll ... [#pragma section documentation](https://msdn.microsoft.com/en-us/library/50bewfwa.aspx) Best regards Espen Harlinn
Espen Harlinn Chief Architect - Powel AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
Edit: Sorry Espen wasn't meant as a response to you but just another suggestion .... need more coffee clearly They are all listed .. pros and cons for each. Read the key point for each. Interprocess Communications (Windows)[^] The easiest for a heartbeat/watchdog function is the WM_COPYDATA call but whether it is best depends on situation if you need more than just a heartbeat. It's definitely on XP and everything since. The C++ sample is on MSDN .. Easy enough to convert to C C++ Windows app uses WM_COPYDATA for IPC (CppSendWM_COPYDATA) sample in C++ for Visual Studio 2008[^] If they are exchanging anything more than a heartbeat I would suggest they look at Using WM_COPYDATA[^]
In vino veritas
-
A mate just called and was picking my brain about how best to handle inter-process communication in plain C. His requirement is he has a monitor app watching a process and if that process goes dark he restarts it. However, sometimes that child app is actually still functioning - it's just a little busy and doesn't respond to the monitor's pings. What he'd like is a way to have the child process increment a counter that the monitor can watch. If the counter is incrementing then it's all good and it'll back off. If the child goes dark and the counter stops incrementing then it's time to kick it. Any thoughts on how best to accomplish this in the simplest, most member efficient way that doesn't require the installation of something like MSMQ? Oh, and the kicker: it needs to support Windows XP and Windows 2003. There's a lot of those installs still out there...
cheers Chris Maunder
Well, You did not mention whether both processes are gui or a non-gui applications. So I will give an answer that will work on both... and is fairly lightweight. It seems like he doesn't really need an IPC implementation... he is probably looking to implement a watchdog. If I were tasked with doing this I would probably go with an event object[^] in a private namespace[^]. He can even populate the lpEventAttributes parameter of CreateProcess[^] to allow the child process to inherit the event handle. WatchDog process would simply loop and use a wait function[^] to wait for the child process to signal "I am alive" then reset the event and re-enter the wait state. If the time-out interval has elapsed and the child process has not responded... restart the process. There are other benefits to using an event object... it can be secured with a private namespace[^]. The other answers from Espen and Leon will work just fine. Although the WM_COPYDATA method would require both watchdog and child process to be GUI threads. Both these methods are also a security risk[^] for commercial products or applications running on critical infrastructure. Best Wishes, -David Delaune
-
A mate just called and was picking my brain about how best to handle inter-process communication in plain C. His requirement is he has a monitor app watching a process and if that process goes dark he restarts it. However, sometimes that child app is actually still functioning - it's just a little busy and doesn't respond to the monitor's pings. What he'd like is a way to have the child process increment a counter that the monitor can watch. If the counter is incrementing then it's all good and it'll back off. If the child goes dark and the counter stops incrementing then it's time to kick it. Any thoughts on how best to accomplish this in the simplest, most member efficient way that doesn't require the installation of something like MSMQ? Oh, and the kicker: it needs to support Windows XP and Windows 2003. There's a lot of those installs still out there...
cheers Chris Maunder
Named shared memory along with named synchronization objects AND monitoring process handles. I've had apps with shared memory queues with both sides waiting on a [local] exit handle, a process handle of the other side, a semaphore and perhaps other objects. For simple monitoring, you could combine a named semaphore and process handle.
-
Well, You did not mention whether both processes are gui or a non-gui applications. So I will give an answer that will work on both... and is fairly lightweight. It seems like he doesn't really need an IPC implementation... he is probably looking to implement a watchdog. If I were tasked with doing this I would probably go with an event object[^] in a private namespace[^]. He can even populate the lpEventAttributes parameter of CreateProcess[^] to allow the child process to inherit the event handle. WatchDog process would simply loop and use a wait function[^] to wait for the child process to signal "I am alive" then reset the event and re-enter the wait state. If the time-out interval has elapsed and the child process has not responded... restart the process. There are other benefits to using an event object... it can be secured with a private namespace[^]. The other answers from Espen and Leon will work just fine. Although the WM_COPYDATA method would require both watchdog and child process to be GUI threads. Both these methods are also a security risk[^] for commercial products or applications running on critical infrastructure. Best Wishes, -David Delaune
Brilliant. Thank you.
cheers Chris Maunder