PC power button - Slightly off-topic
in [Embedded]
|
Prev: VECTORCAST
Next: COMP.DSP 2010 conference update
From: George Neuner on 21 Mar 2010 01:17 On Sat, 20 Mar 2010 11:51:08 +0100, David Brown <david.brown(a)hesbynett.removethisbit.no> wrote: >I'm not thinking that tasks should be killed instead of being asked to >die, but that unresponsive tasks that refuse to die should be killed. Perhaps I wasn't clear before, but that's how AutoEndTasks works. The HangAppTimeout setting controls how long the process has to respond to QUERYENDSESSION. If the process does not respond at all within the timeout period, it is considered hung and killed. The WaitToKill(App|Service)Timeout setting controls how long the process has to respond positively to QUERYENDSESSION once it has first responded negatively ... Windows repeats the query periodically until either the process responds positively or the timeout expires. If AutoEndTasks is not set, these timeouts produces a warning message. If it is set, the processes are killed and no message is displayed. >The "AutoEndTask" behaviour should come automatically after normal >shutdown processing has failed to work - the alternative is a hard reset >which risks all sorts of mess because windows itself hasn't stopped >properly (who cares if a hung process loses data?). The problem is what to do with those pesky processes that refuse QUERYENDSESSION ... they obviously aren't hung completely because they can respond to the inquiry, but regardless they aren't cooperating and may never do so if they are multithreaded or overlapped and some other part of them is stuck. Do you then wait forever? I've seen servers exhaust stand-by power and crash waiting for uncooperative processes to halt. And WRT the file system being messed up ... that is not very likely to happen unless something is actively writing when the reset or power down occurs. NTFS is pretty durable if/when journaling is enabled - I used to write industrial HRT embedded and SRT kiosk-style applications on NT ... even under pretty extreme factory floor conditions (temperature, flaky power, whimsical use of red button, etc.), I hardly ever saw file corruption in any of the systems I worked on. George
From: David Brown on 21 Mar 2010 07:13 George Neuner wrote: > On Sat, 20 Mar 2010 11:51:08 +0100, David Brown > <david.brown(a)hesbynett.removethisbit.no> wrote: > >> I'm not thinking that tasks should be killed instead of being asked to >> die, but that unresponsive tasks that refuse to die should be killed. > > Perhaps I wasn't clear before, but that's how AutoEndTasks works. > > The HangAppTimeout setting controls how long the process has to > respond to QUERYENDSESSION. If the process does not respond at all > within the timeout period, it is considered hung and killed. > > The WaitToKill(App|Service)Timeout setting controls how long the > process has to respond positively to QUERYENDSESSION once it has first > responded negatively ... Windows repeats the query periodically until > either the process responds positively or the timeout expires. > > If AutoEndTasks is not set, these timeouts produces a warning message. > If it is set, the processes are killed and no message is displayed. > OK, now I see how it all fits together. It seems to me then that AutoEndTask should be the default, but with a fairly long timeout. Shutdowns are either initiated by a user, who can then close the uncooperative process (given a long enough timeout), or they are initiated automatically by something like an UPS shutdown, in which case it's better to kill an uncooperative process and lose its data than to wait for power failure to kill everything. > >> The "AutoEndTask" behaviour should come automatically after normal >> shutdown processing has failed to work - the alternative is a hard reset >> which risks all sorts of mess because windows itself hasn't stopped >> properly (who cares if a hung process loses data?). > > The problem is what to do with those pesky processes that refuse > QUERYENDSESSION ... they obviously aren't hung completely because they > can respond to the inquiry, but regardless they aren't cooperating and > may never do so if they are multithreaded or overlapped and some other > part of them is stuck. Do you then wait forever? I've seen servers > exhaust stand-by power and crash waiting for uncooperative processes > to halt. > > And WRT the file system being messed up ... that is not very likely to > happen unless something is actively writing when the reset or power > down occurs. NTFS is pretty durable if/when journaling is enabled - I > used to write industrial HRT embedded and SRT kiosk-style applications > on NT ... even under pretty extreme factory floor conditions > (temperature, flaky power, whimsical use of red button, etc.), I > hardly ever saw file corruption in any of the systems I worked on. > It's true that NTFS systems seldom get seriously corrupted by unexpected resets - that's the idea of the journal. There's still a bit of a risk, and "small" errors do creep in. However, I was thinking here that there are windows processes and services that don't save their data and prepare for a controlled stop until the windows gui is shutting down - these have trouble when you reset or power-cycle the system. To take a very simple example, resize the "quick launch" area on the taskbar - the setting is not saved until shutdown, and is lost on a crash. The most serious risk is of course, the registry files. These can be modified at any time, including when the system is otherwise hung on a failing shutdown - unclean shutdowns always risk registry corruption. It's fortunately rare, but a hosed registry is a real pain.
From: rickman on 22 Mar 2010 13:46 On Mar 21, 7:13 am, David Brown <david.br...(a)hesbynett.removethisbit.no> wrote: > George Neuner wrote: > > On Sat, 20 Mar 2010 11:51:08 +0100, David Brown > > <david.br...(a)hesbynett.removethisbit.no> wrote: > > >> I'm not thinking that tasks should be killed instead of being asked to > >> die, but that unresponsive tasks that refuse to die should be killed. > > > Perhaps I wasn't clear before, but that's how AutoEndTasks works. > > > The HangAppTimeout setting controls how long the process has to > > respond to QUERYENDSESSION. If the process does not respond at all > > within the timeout period, it is considered hung and killed. > > > The WaitToKill(App|Service)Timeout setting controls how long the > > process has to respond positively to QUERYENDSESSION once it has first > > responded negatively ... Windows repeats the query periodically until > > either the process responds positively or the timeout expires. > > > If AutoEndTasks is not set, these timeouts produces a warning message. > > If it is set, the processes are killed and no message is displayed. > > OK, now I see how it all fits together. > > It seems to me then that AutoEndTask should be the default, but with a > fairly long timeout. Shutdowns are either initiated by a user, who can > then close the uncooperative process (given a long enough timeout), or > they are initiated automatically by something like an UPS shutdown, in > which case it's better to kill an uncooperative process and lose its > data than to wait for power failure to kill everything. Is that really the tradeoff? Every time my machine has tried to shut down and a hung application won't let it, the rest of the applications still shut down ok. Then the machine waits for me to do something about that last application. What would be lost if the machine shuts down hard? I can't remember the last time I actually lost anything this way. > >> The "AutoEndTask" behaviour should come automatically after normal > >> shutdown processing has failed to work - the alternative is a hard reset > >> which risks all sorts of mess because windows itself hasn't stopped > >> properly (who cares if a hung process loses data?). > > > The problem is what to do with those pesky processes that refuse > > QUERYENDSESSION ... they obviously aren't hung completely because they > > can respond to the inquiry, but regardless they aren't cooperating and > > may never do so if they are multithreaded or overlapped and some other > > part of them is stuck. Do you then wait forever? I've seen servers > > exhaust stand-by power and crash waiting for uncooperative processes > > to halt. > > > And WRT the file system being messed up ... that is not very likely to > > happen unless something is actively writing when the reset or power > > down occurs. NTFS is pretty durable if/when journaling is enabled - I > > used to write industrial HRT embedded and SRT kiosk-style applications > > on NT ... even under pretty extreme factory floor conditions > > (temperature, flaky power, whimsical use of red button, etc.), I > > hardly ever saw file corruption in any of the systems I worked on. > > It's true that NTFS systems seldom get seriously corrupted by unexpected > resets - that's the idea of the journal. There's still a bit of a risk, > and "small" errors do creep in. > > However, I was thinking here that there are windows processes and > services that don't save their data and prepare for a controlled stop > until the windows gui is shutting down - these have trouble when you > reset or power-cycle the system. To take a very simple example, resize > the "quick launch" area on the taskbar - the setting is not saved until > shutdown, and is lost on a crash. The most serious risk is of course, > the registry files. These can be modified at any time, including when > the system is otherwise hung on a failing shutdown - unclean shutdowns > always risk registry corruption. It's fortunately rare, but a hosed > registry is a real pain. I guess it can happen. But how real a threat is this if everything but one app has shut down? Rick
From: George Neuner on 22 Mar 2010 15:32 On Sun, 21 Mar 2010 12:13:19 +0100, David Brown <david.brown(a)hesbynett.removethisbit.no> wrote: >The most serious risk is of course, >the registry files. These can be modified at any time, including when >the system is otherwise hung on a failing shutdown - unclean shutdowns >always risk registry corruption. It's fortunately rare, but a hosed >registry is a real pain. Yes, the registry is unfortunate ... not for it's existence, but because it is not ACID. The registry wasn't a bad idea, IMO, but the implementation could have been more robust (like a DBMS). George
From: David Brown on 22 Mar 2010 15:51
George Neuner wrote: > On Sun, 21 Mar 2010 12:13:19 +0100, David Brown > <david.brown(a)hesbynett.removethisbit.no> wrote: > >> The most serious risk is of course, >> the registry files. These can be modified at any time, including when >> the system is otherwise hung on a failing shutdown - unclean shutdowns >> always risk registry corruption. It's fortunately rare, but a hosed >> registry is a real pain. > > Yes, the registry is unfortunate ... not for it's existence, but > because it is not ACID. The registry wasn't a bad idea, IMO, but the > implementation could have been more robust (like a DBMS). > Well, I'm not sure I'd think it was a good idea even if it were robust (ACID, as you say) - but I would certainly dislike it less! Windows has its advantages and disadvantages compared to alternatives, but IMHO *nix style text configuration files are much better. Even the simplistic ini files that used to be popular with Windows are much better - it was just /so/ much easier to see what was changed, make copies of settings, modify things manually, find out which settings were for which application, etc. |