h a l f b a k e r yi v n i n seeks n e t o
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
Microsoft provides a means of killing applications that are "not responding". This is useful, but generally results in a loss of data. I would like to see a less drastic standardized vector which would force a program to save its state (making backups of any current documents) and attempt to restart
itself. If a program has multiple documents open, and hangs while doing something with one of them, the document it was operating upon may be corrupted but the others should not.
The idea here is that even if an application is hung, in most cases its data will still be in memory. It should be possible for a recovery routine to analyze the program's allocated memory handles and make sense of what's there. It wouldn't always be perfect, but it could still be better than throwing everything out the window.
[link]
|
| |
//The idea here is that even if an application is hung, in most cases its data will still be in memory// |
|
| |
This problem isn't Windows-specific -
why not reword it to be generic? |
|
| |
Mose of the problems that will cause an application to accidentally overwrite data will result in a reported crash. Usually when an application hangs, it's because it's waiting for some condition that will never occur (deadlock is a special case of this). Data that was in memory will still be there because nothing's happened to change it. Unfortunately, if the application can never escape the spot where it's "waiting", it will never get around to using that data. |
|
| |
Unix's "signal" architecture can be used for similar effect. I've know I've on a couple of occasions used "kill -1" to hit a stuck task (which let me save its data before exiting). |
|
| |
What if the process of backing up the current documents corrupts them or the user environment? Good goal, though. |
|
| |
Anything that is an improvement on the
pesky recovery process that exists in
Windoze at the mo would be most
welcome. A crash with a recovery of 4
documents open at the time is time-
consuming to say the least. |
|
| |
How about an email being produced
when the crash occurs that actually
produces some feedback - like 'sorry,
we are creditng your PayPal account
with $100 for the inconvenience' or
something? |
|
| |
Basically this is an automatically interpreted memory dump. Since memory dumps used to be standard practice whenever a program crashed I think this could still work--the trick is knowing where in memory the data you want was stored in the first place. In the old days, when 1k of memory was very impressive, a knowledgable individual could search the memory dump by hand and sometimes actually determine the cause of the crash (even if it was 10 pages of raw hexadecimal). These days, memories typtically consist of hundreds of megabytes, of which I doubt more than 500k is actually your data. Even if you throw out all the obviously empty registers you've still got several megabytes at least just of memory used to run the operating system. Finding the right data in all this would be very hard indeed. And if your data was stored in virtual memory for some reason then it would be even harder to find. |
|
| |
This all said, I think it is possible. If you had an daemon whose sole job is to monitor the location of all document data at all times, then presumably this process would still know where everything was even if another program crashed. Of course, if the daemon crashed you're screwed, but it's a simple enough program I think it could be made pretty foolproof. |
|
| |
yellowcyclist: on a unix system I used, I'd get an email from elvis (the text editor) if my session died (usually from NO CARRIER). |
|
| |
5th Earth: the application doing the recovery would generally have access to the data required to make sense of memory contents, so recovery should not be too difficult. |
|
| |
DrCurry: The risk of corrupting user documents is the reason for making a backup of the last saved copy of a docuent before saving a 'recovery' copy. |
|
| |
First to zigness comment "You think this why?" it will still be in memory because one of the wonderfully evil but useful in this case is that windows never dumps things from ram unless forced now most new programs know this and tell windows to dump the stuff it put in ram when it closes. |
|
| |
Seconded thing is in response to the thing a bought finding what you need well windows NT witch XP is based on tracks what program uses what section of the ram so that will shorten the search considerably. |
|
| |
Now I like this Idea it just needs to built a bun for you. |
|
| |