Garantie Codeausführung auch auf Prozess beenden

Question

Ich brauche einen Teil des Codes (der Zustand speichern) auf den Prozess auszuführen, zu stoppen. - durch sich selbst, durch den Benutzer, durch den Task-Manager, etc.

Ist es möglich?

try {} finally {}, AppDomain.ProcessExit, IDisposable, destructor, .., was als nächstes versuchen?

Answer 1

Wie andere darauf hingewiesen haben, gibt es keine Möglichkeit, beliebigen Code in Ihrer Anwendung ausführen kann, wenn es Killed von Operating System oder User zu sein. Deshalb sein genannter Killing.

Wenn der Staat spart, ist ein wichtiger Teil Ihrer Anwendung, sollten Sie einen ähnlichen Ansatz wie ein Datenbanksystem übernehmen. Die Implementierung transaction log, die Schaffung checkpoints usw., die am nächsten ist man bekommen kann.

In diesem Fall, wenn die Anwendung Wiederbelebungen (wird nachdem er killed re-run), kann sie diese transaction logs für alle anstehenden Aktualisierungen oder letzte Statusänderungen überprüfen.

Other than that, es hängt wirklich davon ab, was Sie tun wollen. Und auch, warum kamen Sie auf diese Idee? Können wir mehr Details bekommen? Kann hier jemand hat eine bessere Alternative.

Answer 2

The whole point of a process being killed ungracefully is that it just stops what it is doing. I can't really see a way around that.

Answer 3

You need to think about why your program is exiting. If it is because of an error, then you can use try/catch. In unix terms, what goes on when the process manager halts a process is a kill (i.e. sends a SIGKILL signal) which doesnt allow the program to do anything before the process is exited. What many viruses do is have two processes (possibly with shared memory to avoid constant data synchronization), each monitoring the state of the other and when one goes down, the other respawns it. Perhaps a second process could monitor and save the state in a similar way for your case. The other kind of signal though is a SIGTERM. This signal is sent when you tell your computer to restart but there are processes running. The kernel allows the programs to try and quit on their own, but eventually will ask the user if it is okay to kill the program. If you want to handle SIGTERM lookup handling signals. Ultimately the only solution that I know of to the SIGKILL is the two process solution.

Answer 4

I was looking around for a somewhat different reason than what is posted, but I came up with a pretty good solution for myself and it might useful to state here:

NOTE: To those that know what it is, this is essentially the 'Heartbeat' design pattern.

1) In addition to the code running that will 'die' (ie be killed), add code to this project such that it spawns a thread (or possibly another method?) upon initialization, and all the thread does is run a never-ending while loop (but make sure it sleeps at least a few seconds or even 1 minute between iterations) and in the while loop, record an indicator to indicate your app is 'alive' (ie the 'heartbeat'). I personally recommend setting a value in either the DB, or perhaps a file, that is the current timestamp (ie DateTime.Now)

2) Now that you are recording the 'heartbeat', create another app (ie another process) that does nothing but reads the heartbeat value (ie the current timestamp) and does this in a never-ending while loop. Once its determined that the heartbeat value is 'bad' (ie maybe if, say, HeartBeatTimestamp + 5 min < DateTime.Now), you can now run your code that you desire to run 'once the process is killed'

Hope this helps :) Feel free to research the 'Heartbeat' design pattern from other resources to if you want to know more!

Cheers,

Jeff