Can't remember the exact messages >_<
I still hold the opinion that continuing to execute in any way at all, after program state has been corrupted, is dangerous. Especially if your crash handler does something like writing to a file.
If the world is whacked, who knows what might happen. It's like being on a psychedelic trip. You might think you're smelling roses when in fact you're stabbing someone in the chest.
That too -- single-threaded apps tend to do this if they're CPU intensive (programs like BSP compilers, for example).
EDIT: Actually on Mac, maybe you'd use ktrace instead. I'm not an expert either.
That metaphor completely fails to make me see your point.
That's nonsense. No matter how much a GUI program does, it should always prioritize (and thus handle in a timely manner) user interaction. Even if it is only to say, "Go away, I'm busy."
I would argue that for an event driven app this should be considered unacceptable.Quote:
Originally Posted by brewbuck
Agreed. The so called 'error' may not be that of the vehicle but definitely of the driver. In this case, a program that is not responding due to being 'busy' is unaccetable behavior in any event-driven operating system (e.g., all modern OS's). Failing to respond is considered a badly behaved operating system and, in the good old days of Windows '95 (cringe), that sort of an application would often have the effect of bringing the entire OS to its knees which would force the user to restart their computer. It's one reason why programs are allowed to create separate threads -- throw the cpu heavy stuff in the one thread and respond to the OS with the main thread.Quote:
Originally Posted by CornedBee
Thankfully modern OS's handle misbehaving applications in a better way (they tell you that the app is misbehaving and are prepared to kill it).
Very commonly for apps that otherwise respond just fine, someone somewhere will provide it more data than it can process in an acceptable amount of time, and cause it to become "not responding". I have a feeling that putting up the wait cursor stops that, but I could be wrong.
It's not always easy or even practical to process user input while you're busy.
Of course we should all try hard to keep our app responsive, for our users sake.