Re: RLIMIT_FSIZE and SIGXFSZ

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> [...SIGXFSZ...]
>> It seems to me it would be more useful to do something like what
>> RLIMIT_CPU does, and generate SIGXFSZ for such operations, but fail
>> them only when the size exceeds the hard limit.  [...]
> So I think the CPU limit signalling is treated as a special case
> because it's pretty useless to deliver a signal whose handler you
> can't execute because you're past the CPU limit.  Otherwise (all
> other limits) you get denied once you reach the soft limit, and I
> think that's the way things are intended to work.

RLIMIT_FSIZE is already special in another way, a way similar to
RLIMIT_CPU: it generates a signal.  You don't get a SIGXPROC when
trying to fork() when you're over RLIMIT_NPROC.  You don't get SIGXFD
when running into RLIMIT_NOFILE.  (Though perhaps you should.  Maybe
SIGRLIMIT, with the second handler arg saying which limit?)

If the write() simply failed showing EXFSIZE or some such, I might
agree with you.

> I think what you want is an additional signaling threshold that can
> be manipulated separately from the limit.

Sort of.

For my immediate purposes, I don't even _need_ to use RLIMIT_FSIZE at
all; it's simply a covenient way that's already there to hear about the
condition I care about.

I've made the changes I sketched for 4.0.1 and they do give the
behaviour I wanted/expected.  I'm going to add them to 1.4T and 5.2
(the other two versions I run) for my own use; I'll let you people hash
out whether NetBSD wants them.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B