1

In the C# 7.0 in a Nutshell book, I've read something that seems a bit confusing.

Unlike with the DomainUnload event, ProcessExit event handlers are timed: the default CLR host gives event handlers two seconds per domain, and three seconds in total, before terminating their threads.
(Chapter 24 - Page 956)

What does 2 Seconds mean for a Code block (i.e. event handler)?
Seems it depends on how much time is dedicated to the current process - as this 2 seconds is generally shared between processes by the OS.
So it's indeterministic that how much work is allowed to be done in the "process exit event handler" before the process is killed.

Emran
  • 544
  • 7
  • 26
  • 2
    It almost certainly means that somewhere in the CLR there's a thing that tells the kernel to wait 2000 milliseconds for an object to become signaled (possibly the thread itself) before terminating things. Of course that's not exactly 2 seconds because the OS isn't real-time, but it should be *good enough*. Unless your system's thrashing, waiting 2 seconds will seldom turn out to be waiting 10 seconds, and never waiting 0.5 seconds. Getting a "deterministic" amount of work done is obviously not the goal here, it's keeping the authors of these event handlers honest when we've promised an exit. – Jeroen Mostert Aug 07 '18 at 10:46
  • "shared between processes" makes no sense. No sharing, it only applies to your process and only to your ProcessExit event handler. You know how much work it has to do, you wrote the code for it. Maybe there are other event handlers in C# code that you did not write, if those are a problem then you tend to need to use your telephone. – Hans Passant Aug 07 '18 at 11:08
  • @JeroenMostert Your comment, IMHO, is the answer. Please post it as an answer. – Mohammad Dehghan Aug 07 '18 at 11:57
  • @HansPassant Suppose I know how much work I have totally in all exit event handlers of my process: (i.e.) About 100000000 CPU ticks! So would you please tell me how much **time** does it take?! The key point is that **time** has no relationships to **number of ticks** a code spends. (As the OS theoretically **can** delay a single line of code to get executed after an hour!) – Emran Aug 07 '18 at 12:11
  • 1
    That is a fairly nonsensical proposition. If it takes a hour then the user will be quite happy that this 2 second timeout exists. This policy was added in .NET 2.0 because there was a lot of bad .NET 1.x code that got this wrong. Deadlock is a pretty standard hazard when writing this event handler. – Hans Passant Aug 07 '18 at 12:20
  • 2
    If you know exactly how much work there is, and you absolutely need that work to be done even if it could take more than two seconds of wall clock time, then these event handlers are not the place to do that work. You can integrate a mechanism into the application's regular logic instead for when ending the process is voluntary, and/or write recovery code to handle partially broken state on startup when it's not. Exit code that needs a lot of time is badly written exit code, and the CLR terminates it as a service to the user, not as part of a careful contract with the developer. – Jeroen Mostert Aug 07 '18 at 15:55
  • @JeroenMostert Your comment resolved my mistake! Specially the sentence: "the CLR terminates it as a service to the user, not as part of a careful contract with the developer". Please post it as an answer. Thank you so much! – Emran Aug 08 '18 at 04:26

0 Answers0