On Fri, 24 Mar 2000, James Sutherland wrote:
> No; for the typical case, you just install a signal handler once, when
> the app starts, then you can call malloc() and write to the resulting
> address without any further checks at all.
This does not distinguish between the segfault because of OOM (which can
be recovered from) and the segfault because of a wild pointer dereference
(which probably can not be recovered from). Thus the need to switch
signal handlers around- outside of the xmalloc() you can assume that all
segfaults are due to wild pointers (because xmalloc touches all memory
before returning it), within xmalloc() you can assume that all segfaults
are due to OOM.
> Much better, IMO, to replace that whole mess with a nice "OOM signal".
> No need to check return values, no need to compare things - MUCH less
> overhead in the typical case (success).
SIGOOM- while not, IMHO, the correct solution- would certainly be better
than what we have today. Remember that the default behavior of SIGSEGV is
to dump core (see signal(7))! It'd also automatically differentiate the
wild pointer error and the OOM condition.
Brian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:13 EST