[ On Fri, December 18, 1998 at 20:38:53 (+0100), Ignatios Souvatzis wrote: ]
> Subject: Re: userid partitioned swap spaces.
>
> With UVM, it gets such a signal. At least thats promised in the docs.

I see one place where KERN_RESOURCE_SHORTAGE is returned by UVM (when
there's no more anonymous VM left), but I don't see yet where that
results in a signal.

There seem to be other places in UVM though where the comments indicate
that various conditions can still cause hangs, etc.

The question I have though is still what should this signal be?  I'd
like to see either a SIGDANGER, or perhaps the SIGOOVM signal I proposed
earlier.

In the case of VM exhaustion when growing the stack I'm not sure what
the process can do to recover....  Perhaps the system should try it's
best to free VM and allow the stack to grow in such cases (at least
until the the process reaches it's alloted maximum stack size).

However when a process encounters VM exhaustion somewhere other than
from stack growth, just because the system has over-commited swap space,
I don't think it should be that process that's automatically forced to
die, esp. if it's either a critical process, or one that wouldn't result
in sufficient recovery.  Signals such as SIGDANGER or my fictional
SIGOOVM are methods of electing one, or more, more appropriate
volunteers (with each having a different default policy).

BTW, SIGSEGV might be the wrong choice, in my opinion, for a signal
that's intended to actually kill a process due to a VM exhaustion
exception.  For starters it's catchable, and most programs that catch it
expect entirely different problems have happened when it's raised (such
as RLIMIT_STACK has been exceeded, or a pointer has gone wild, or in the
case of the ancient Bourne shell, that the heap is exhausted).  The only
standard signal that seems to fit the semantics of VM exaustion
exceptions seems to be SIGKILL, esp. for something like stack space
exaustion.  Even using SIGSEGV for RLIMIT_STACK seems wrong to me -- I
hate to overload things like that with completely different meanings.
(but of course Unix is full of such confusion, esp. with errno).  It's
too bad there's no SIGXSSZ (eXceeded Stack SiZe, companion to SIGXFSZ
and SIGXCPU) too....

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>