Dead man' switch for -stay_open

[ScannerBoy]

Working under Win 10 and using MSVC 2019 with wxWidgets as a framework, I have been able to make the -stay_open option work to my satisfaction.

Still, maybe I missed something, but during development, I find a lot of orphan instances of exiftool left running after a bad exit (read: crash).

My concern is that something like this might happen, even once the app is debugged well enough to behave properly and terminate cleanly, with code to shut down exiftool on the way out. Murphy's law ...

Some servers I have used, include a separate process to restart the server if it should exit unexpectedly.

In my case, the opposite case holds. I would like to make sure any exiftool process I had started does not outlive its usefulness.
This got me looking at a process, started along with my app and exiftool and listening for a 'poke' from my app, say once per second. If this 'guardian' does not get an input message from it 'parent', it shuts down exiftool and then itself ( after some reasonable number, say 10 or 20 missed 'pokes'.

My question: is such a 'feature' already available in exiftool when it is running as a result of the -stay_open option and I have just missed finding the proper reference.
If not, is/would it be possible to add such a feature, a sort of 'dead man' switch?

[Phil Harvey]

If you look at the C++ ExifTool wrapper that I wrote, you will see how I handle this.  If the ExifTool process dies unexpectedly, then its parent's PID will change.  I set up a watchdog process to monitor this, and use it to kill the ExifTool process if necessary.

- Phil

[ScannerBoy]

Because Win is not Posix compliant, I don't see a way to use the C++ wrapper - and I have tried, several times.
One option I have seen mentioned is to install the Boost libraries - a huge overhead.
Perhaps, there are other ways, but I have not found a set of other libraries which would make it possible to compile & debug an app using the wrapper under MSVC IDE :-(
I have looked at MingW and Cygwin, but a switch would entail a whole lot of other issues for me.

Instead, I am using wxWidgets functions which allow me to start Exiftool with the -stay_open option and send data to it and read its output via pipes connected to stdout & stdin.

It all works well enough, except, if I abandon a debug session and don't manually clean up any left over instances of Exiftool, these simply stay in memory. Whether these are loading up the CPU, I have not investigated, but I can use the Task Manager to kill then manually.

Whether this approach differs significantly from what you describe or what the wrapper provides, I have no idea.
All I see is the orphan Exiftool processes.

From your description, though, once the parent process has gone away, I don't see any evidence that the Exiftool instances remove themselves automatically.

Once my app is debugged well enough, I don't expect to leave too many of these orphans around, but, I Murphy  is still around and active ....

[Phil Harvey]

Yes, these zombie processes shouldn't happen under normal circumstances, but that doesn't mean you shouldn't handle them if you can.  There should be a way to get the process ID and be sure it is killed before you exit your program.

- Phil

[ScannerBoy]

Agreed; my app is handling this properly on a clean exit.
What I was concerned is for times when the calling app does not!