[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: RLIMIT_FSIZE and 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.
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
Main Index |
Thread Index |