Date: Thu, 14 Jan 1999 01:57:43 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: peter.jeremy@auss2.alcatel.com.au (Peter Jeremy) Cc: hackers@FreeBSD.ORG, tlambert@primenet.com Subject: Re: Problems with 3.0 Message-ID: <199901140157.SAA12304@usr02.primenet.com> In-Reply-To: <99Jan14.104510est.40358@border.alcanet.com.au> from "Peter Jeremy" at Jan 14, 99 10:45:41 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >Another one recently discovered is that it *appears* that you can
> >map (read only) the same file twice letting the system decide where
> >to put it (pass NULL as binding location), and the second time the
> >system will return the same address as the first time, instead of
> >doing the right thing and setting up the mapping at a different
> >location.
>
> Why is this behaviour wrong? Given that both mappings are read-only
> and you haven't said that you want it mapped at a specific location,
> why shouldn't the system just reuse the pre-existing mapping? This
> is definitely easier for the kernel, and reduces system resource
> requirements (page table entries and suchlike).
Because it doesn't reference count the unmappings.
This damages data encapsulation sematics. If I have:
some_context *
f1_open()
{
some_context *ctxp;
ctxp = (some_context *)malloc(sizeof(some_context));
ctxp->sc_region = mmap( ...);
}
different_context *
f2_open()
{
different_context *ctxp;
ctxp = (different_context *)malloc(sizeof(different_context));
ctxp->dc_region = mmap( ...);
}
then I'm screwed, since if I:
c1 = f1_open();
c2 = f2_open();
do_some_stuff( c1);
f1_close( c1); /* XXX blows c2's head off*/
do_different_stuff( c2);
f2_close( c2);
references to c2->dc_region will explode because the region is no
longer valid.
If this type of thing is OK, then I'm anticipating your implementation
of WSOCK32.DLL for FreeBSD so we can "take all the socket bloat out
of the kernel, since kernel-based resource tracking is unnecessary"...
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901140157.SAA12304>