Re: Big strings => panic

• Date: Fri, 19 Apr 1996 12:44:26 PDT
• From:
  m.sanderson@student.anu.edu.au (Matthew Sanderson)
• Content-Type: text/plain; charset="us-ascii"

>It's not a "bug" per se, nor is it something easily fixed.

A feature, then :)

>What happens is simply that when a variable (list or string) gets very
>large, the server runs out of memory.

Uh-huh. Thanks.

>When
>the server runs out of memory, it panics -- and in this case probably
>produces one *very large* panic dump.

Seems like a bit of a design bug to me: we've run out of memory, oh I know,
let's panic...

>The MOO execution unit does not impose any limits on how much memory a
>task can use: how big variables can get or how many there can be.
>Therefore, there's no way for the server to tell when this is about to
>happen.  (And, Pavel's said previously that there's no easy way to make
>the server impose limits on task size.)

Granted; would it then be possible to degrade slightly more gracefully,
such as kill the huge task, rather than panicking? Malloc fails, kill the
MOO task, sort of thing. I don't see that a server panic is either
necessary or desirable or unavoidable in this situation.
Although I realise it's a danger one has to live with, it would be really
nice if giving someone a progbit did not give that person the power to
panic the MOO. 1.8.0's task-quotas is a solution to the problem of
forkbombs... but this problem remains (and some others).

Matthew Sanderson
m.sanderson@student.anu.edu.au
The Australian National University, Canberra.

===========================================================================
"Computers in the future may weigh no more than 1.5 tons."
     --Popular Mechanics, forecasting the relentless march of science, 1949
===========================================================================

• Re: Big strings => panic
• From: Brandon Gillespie <brandon@tombstone.sunrem.com>

• Prev: Re: Big strings => panic
• Next: Re: Big strings => panic
• Index: MOO-cows
• Thread: MOO-cows