Killing an orphan process when the plugin has died

[ubu]

I have the same trouble with ZProcess which spawns ffmpeg.exe trying to transcode on the fly for viewing files on the MVP...

What I did was:

ZProcess is called by GB-PVR.

It spawns ffmpeg.exe

It also spawns a watcher program (hunter.exe) that checks the PID of GB-PVR and the ffmpeg.exe window to see if they are both up and running.

If I kill GBPVR in Task Manager, Hunter sees it disappear and kills the ffmpeg.exe then exits...

If I kill ZProcess in Task Manager, Hunter sees it disappear and kills the ffmpeg.exe then exits...

If ffmpeg.exe crashes (an error or something) Hunter just exits.

If I exit the transcode process in GB-PVR, (graceful exit) GB-PVR kills ZProcess, and hunter takes care of ffmpeg.exe and itself.

It's not as classy as a real programmer might do, but it's been quite stable.

That's pretty much what I had in mind until Brian suggested using a Windows service. The Windows service approach seems like it will provide an "industrial strength" solution. Hopefully I can make it generic enough that it could be used for ffmpeg, mencoder (or any long running process that needs to be automatically killed if its parent dies) as well as for vlc.

By using "stay alive" calls from the parent to keep the process running, I don't have to worry about who died or why. If nobody sent a "stay alive" message for the past 30 seconds, I kill the process unconditionally (and, optionally, delete the output file created by the process).

Not quite sure what a "real programmer" is. I think it's probably a state of mind.

[bgowland]

Thanks, Brian. I waited until I'd tried this before responding to you. Your proposed approach is just what the doctor ordered. Seems like it totally solves my problem.

Cool. Glad to be of help.

I'd never used a Windows service before but it turned out to be fairly easy to put together.

I wrote my first about 10 years ago for a mailing list distribution service running on NT v3.5. It was in raw C but still not too complicated - just a lot more lines of code. I got hooked on services at that point and use them whenever appropriate. So long as the base service code has all the relevant exception handling etc. they're rock solid.

I used a simple TCP Channel, as you suggested.

These are sweet - I like the way they're pretty simple to implement and you can pass anything you like through them. I use a message handler interface like this...

Code:

public interface IMessageHandler
{
    bool ProcessCommand(MyRemoteCommand command, object data);
}

MyRemoteCommand is just an enum so I use a 'switch (command)' at the remote end to call whichever method applies. Each method is then able to cast 'data' to whatever object type is appropriate.

Now I'm worrying about "What if someone kills both GB-PVR and the VLC recording service?"

Herein lies madness.

Cheers,
Brian

[bgowland]

It's not as classy as a real programmer might do, but it's been quite stable.

Not quite sure what a "real programmer" is. I think it's probably a state of mind.

lol - I agree.

I started programming in the late 1970s, when the word 'hacker' just meant someone that had to make it up as they went along because there wasn't much in the way of documentation around.

These days I still hack stuff together if I need a quick fix for a problem. Sometimes I get time to do something elegant. Mostly it's something in between. If it works, it works.

Cheers,
Brian

[zehd]

lol - I agree.

I started programming in the late 1970s, when the word 'hacker' just meant someone that had to make it up as they went along because there wasn't much in the way of documentation around.

These days I still hack stuff together if I need a quick fix for a problem. Sometimes I get time to do something elegant. Mostly it's something in between. If it works, it works.

Cheers,
Brian

here, here

[zehd]

That's pretty much what I had in mind until Brian suggested using a Windows service. The Windows service approach seems like it will provide an "industrial strength" solution. Hopefully I can make it generic enough that it could be used for ffmpeg, mencoder (or any long running process that needs to be automatically killed if its parent dies) as well as for vlc.

By using "stay alive" calls from the parent to keep the process running, I don't have to worry about who died or why. If nobody sent a "stay alive" message for the past 30 seconds, I kill the process unconditionally (and, optionally, delete the output file created by the process).

Not quite sure what a "real programmer" is. I think it's probably a state of mind.

Yeah I was thinking my 'hunter.exe' would be nice to share, but I like the service idea. I built my first service a long while back in VB4, and it was a kludge (but it worked). When I came out of 'retirement' to write ZProcess I thought I'd be better off staying away from services for now...