> Of course this is a programmer error, and the hardware is > doing the right thing. But is the OS doing the right thing? > The programmer didn't ask the OS to abort the program.
Ostensibly the reason that the OS is limiting access is to do resource access or utilization controls. If the application is attempting to do something that violates the controls placed on a resource, then the OS has two choices -- extend the controls according to a policy, or deny the request. In either case, the application has to cope with either a soft failure or a hard failure. If the application programmer doesn't deal with a hard failure, or the system programmer doesn't deal with it by having a soft retry exit like ESTAE active, then what's the OS supposed to do? Guess? The Symbolics OS had a policy setting for this sort of thing (setq `sym-access-violation-policy `some-kind-of-bitmap-vector-that-I-can't-remember), but it did have a bunch of stability problems, so the default was to abort processes that violated their resource constraints. I don't know too many others that have tried to handle this beyond the "give the control back to the app, and default to kill if no app handler".
