[Sbcl-commits] master: sunos-os.c: Do not lose on mmap failure

[David L. <lic...@us...>]

The branch "master" has been updated in SBCL:
       via  2b67d29226463dff2ee971553c6a1eaf3f1e09d0 (commit)
      from  89d479da5c74575f21a52af0055e8f6dd85edc30 (commit)

- Log -----------------------------------------------------------------
commit 2b67d29226463dff2ee971553c6a1eaf3f1e09d0
Author: David Lichteblau <da...@li...>
Date:   Tue Sep 18 17:11:13 2012 +0200

    sunos-os.c: Do not lose on mmap failure
    
    Brings this platform in line with other POSIX backends.  It is desirable
    that we do not `lose' just because too many threads have been created,
    for reasons of user-friendliness -- and also because individual
    ill-behaved tests should not cause the entire run-tests process to fail.
---
 src/runtime/sunos-os.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/src/runtime/sunos-os.c b/src/runtime/sunos-os.c
index c1925ed..cab00ba 100644
--- a/src/runtime/sunos-os.c
+++ b/src/runtime/sunos-os.c
@@ -51,7 +51,13 @@ os_vm_address_t os_validate(os_vm_address_t addr, os_vm_size_t len)
 
     if (addr == MAP_FAILED) {
         perror("mmap");
-        lose ("Error in mmap(..)\n");
+        /* While it is generally hard to recover from out-of-memory
+         * situations, we require callers to decide on the right course
+         * of action here.  Consider thread creation: Failure to mmap
+         * here is common if users have started too many threads, and
+         * often we can recover from that and treat it as an ordinary
+         * error. */
+        return 0;
     }
 
     return addr;

-----------------------------------------------------------------------


hooks/post-receive
-- 
SBCL