>> [...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 [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
