Subject: Re: mmap, siginfo
To: None <email@example.com, firstname.lastname@example.org>
From: r.o.s.s <email@example.com>
Date: 02/17/2002 18:57:52
We don't apply the datasize limits very seriously to mmap(2) calls,
but we do check that any one call doesn't bust the limit. Effectively,
cmucl was intentionally activating a bug in mmap(2) instead of clearing
the soft setrlimit(2).
Sometimes I think those limits are more trouble than they are worth,
although mmap(2) would have returned a reasonable ENOMEM in the
limit-busting case. Or, you could argue that the goofy check in
mmap(2) is worse than no check at all, because it's confusing.
> From: Thor Lancelot Simon <firstname.lastname@example.org>
> On Sun, Feb 17, 2002 at 04:30:00PM -0600, John R Towler wrote:
> > Difficulties apparently are manifest in the OS facilities desired in
> > the new, experimental port of cmucl to NetBSD/x86. Wrt the comments
> > below, the facilities desired are
> > ((a) the ability to map memory in chunks >= 128M
> I don't understand what the problem is, here. I mmap more than 128MB
> at a time with some regularity; no problems to report.
> Perhaps the author of the comment you enclosed didn't check that his
> resource limits were set appropriately? I note that:
> 1) The default "datasize" limit is 128MB
> 2) Many other Unix variants incorrecly *don't count mmap allocations
> against *any* resource limit *at all**, allowing the use of mmap()
> to completely bollix up the system.