On Dec 30, 8:03 am, Volker Braun <[email protected]> wrote: > No, if you mmap() with MAP_NORESERVE then it always succeeds (if the > processor can address it, 16TB on x86_64). Reads always succeed. But > whenever you write to the memory map, you can get a SIGSEGV.
In the face of Linux's overcommit strategy and its OOM-killer solution isn't this a bit academic? I quote from the mmap manpage bugs section: On Linux there are no guarantees like those suggested above under MAP_NORESERVE. By default, any process can be killed at any moment when the system runs out of memory. In particular, it's not so clear there will even be a SIGSEGV to recover from. We have one example of a library for which memory extension was improved upon integration with sage: libpari. However, there the memory management was set up differently, already allowing for manual extension. That was just automated. Doing this on libgap sounds like a LOT of work. Especially if the gap people are already thinking about redoing their memory management, it sounds like a bad investment. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
