Ask stupid questions and you'll get a stupid answers, was: Technological advantages over Linux

Steve O'Hara-Smith steve at sohara.org
Mon Jul 27 11:56:41 UTC 2020


On Mon, 27 Jul 2020 07:39:42 -0400
Aryeh Friedman <aryeh.friedman at gmail.com> wrote:

> On Mon, Jul 27, 2020 at 7:34 AM Steve O'Hara-Smith <steve at sohara.org>
> wrote:
> 
> > On Mon, 27 Jul 2020 12:25:02 +0100
> > RW via freebsd-questions <freebsd-questions at freebsd.org> wrote:
> >
> > > On Mon, 27 Jul 2020 02:09:21 +0200
> > > Polytropon wrote:
> > >
> > > > On Sun, 26 Jul 2020 21:39:15 +0100, Steve O'Hara-Smith wrote:
> > >
> > > > >   The trouble is there really isn't anything else the OS can
> > > > > do because nobody ever thought to implement
> > > > > SIG_RELEASE_SOME_MEMORY_PLEASE which would probably be the ideal
> > > > > solution provided at least *some* programs responded to it.
> > > >
> > > > As you mentioned, it depends on the problem programs ("apps") to
> > > > actually receive and act upon such a signal.
> > >
> > > It's not implemented as a signal, but I gather that OS X has a message
> > > of that type. There is an incentive to support it as makes the process
> > > less likely to be killed.
> >
> >         Somehow I just knew it wasn't a new idea.
> >
> 
> The problem of course if every program played nice there would be no need
> for OS's.

	It doesn't need every program to play nice - putting hooks in
common libraries would go a long way. In the end though you're right there
is nothing the OS can do about a process that keeps on grabbing more memory
except kill it when it hits a limit.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/


More information about the freebsd-questions mailing list