On Thu, 03 Feb 2000, Kelly Lynn Martin <[EMAIL PROTECTED]> wrote:
> On Thu, 3 Feb 2000 19:33:31 +0100 (CET), [EMAIL PROTECTED] said:
> > If you have a shared maschine the best would be to let the
> >administrator choose how much memory each user will get because
> >users'll ALWAYS try to get what they can even if it makes no
> >sense....
> It might be a good idea to have a compile-time configuration option
> for maximum cache size, 

I disagree.  This would only encourage some users to re-compile their
own version of the Gimp in a private directory in order to get around
the hardcoded limits.  Being a system administrator myself, I believe
that an admin should always suggest some limits (and maybe use some
social engineering to encourage users to respect these limits) but
should avoid hard limits.  Because most users do not like hard limits
and they start wasting their time and the admins' time trying to work
around them.

>                         and it might also be a good idea for gimp to
> check its ulimits and adjust its cache size so as to avoid running
> over its data segment limit or maximum resident set size.  Some
> admins use these as a way to prevent resource hogging.

That would be a good idea, indeed.  If the limit on memory is rather
low but there is still some room left on the disk, then it would be
good to lower the tile-cache-size.  This would ensure that the Gimp
would not die prematurely because of malloc problems when it could
have swapped some tiles to disk.

On the other hand, if ulimits are used to limit the maximum file size
or CPU usage, there is not much that we could do about it.  Same if
disk quotas are activated.  The Gimp can have some control over its
memory usage, but many parts of the code assume that the disk space is
unlimited (or is not the main constraint).


Reply via email to