mmap buckets are a bit bogus

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

LARGEFILE support errors threw me into win32's mmap code.  This got me looking
at the mmap bucket support.  I'll accept we should never be dumping 4+GB out the
socket, but it opened my eyes to this quandry.

What ARE the offset and size arguments?  If the mmap_create call sets aside a
maximum 'window' into the file, and mmap_offset merely adjusts the offset, then
I argue mmap_offset is worthless.  IF, otoh, mmap_offset allows us change the
'viewport' offset, then we need to know what the size of that viewport became.

It's a goofy semantic altogether.  Either mmap_offset grows a size, or goes away.
It doesn't matter to me if its a size that the user specifies, or only a return
value for the size of the available window.

Bill

p.s. I'm offline for a day and a half, if you find problems with the largefile
stuff, sendfile, read, write or seek changes, please feel free to fix them and
I'll review after they are committed.

Re: apr_mmap interface (was: Re: mmap buckets are a bit bogus)

["William A. Rowe, Jr." <wr...@covalent.net>]

From: "Greg Stein" <gs...@lyra.org>
Sent: Wednesday, June 06, 2001 8:53 PM


> Euh... to be clear, this isn't related to the MMAP buckets, right? You're
> talking about the MMAP interface.

Correct, I stumbled on the abuse because the MMAP bucket read is the only abuser
of this sillyness.

> I would agree: the offset seems rather bogus. Why not just return the
> ptr/len of the mmap and let the user add to the pointer (as necessary).

Exactly.  Ryan mentioned we need that pointer to deallocate later, but if you
read the win32 implementation, we already had to stow that as a set-aside.  
Win32 required a page-aligned map, which I didn't believe we should/could
guarentee the caller would pass.

> Oh, christ. Looking at the function, that is exactly what it does. A pointer
> add. Let's toss the darn function.
> 
> And while looking at apr_mmap.h: why is the structure public? Ack! That guy
> should be private.

Ryan was quite sure we needed the members for something, but I absolutely agree.
If we were missing the length or something, then let's just address that.  If we
needed it within apr for shmem or something, we can always (within apr) peek
under the covers, and grab the private mmap.h file.  Better yet, add the missing
accessor function.

Re: apr_mmap interface (was: Re: mmap buckets are a bit bogus)

[rb...@covalent.net]

On Wed, 6 Jun 2001, Greg Stein wrote:

> Euh... to be clear, this isn't related to the MMAP buckets, right? You're
> talking about the MMAP interface.
>
> I would agree: the offset seems rather bogus. Why not just return the
> ptr/len of the mmap and let the user add to the pointer (as necessary).
>
> Oh, christ. Looking at the function, that is exactly what it does. A pointer
> add. Let's toss the darn function.
>
> And while looking at apr_mmap.h: why is the structure public? Ack! That guy
> should be private.

It was private.  The problem is that the buckets really needed it to be
public.  The only really sane way to implement an MMAP, is as a void
pointer and a length, but for some reason some platforms require more than
that.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------

apr_mmap interface (was: Re: mmap buckets are a bit bogus)

[Greg Stein <gs...@lyra.org>]

Euh... to be clear, this isn't related to the MMAP buckets, right? You're
talking about the MMAP interface.

I would agree: the offset seems rather bogus. Why not just return the
ptr/len of the mmap and let the user add to the pointer (as necessary).

Oh, christ. Looking at the function, that is exactly what it does. A pointer
add. Let's toss the darn function.

And while looking at apr_mmap.h: why is the structure public? Ack! That guy
should be private.

Cheers,
-g

On Wed, Jun 06, 2001 at 02:04:41PM -0500, William A. Rowe, Jr. wrote:
> LARGEFILE support errors threw me into win32's mmap code.  This got me looking
> at the mmap bucket support.  I'll accept we should never be dumping 4+GB out the
> socket, but it opened my eyes to this quandry.
> 
> What ARE the offset and size arguments?  If the mmap_create call sets aside a
> maximum 'window' into the file, and mmap_offset merely adjusts the offset, then
> I argue mmap_offset is worthless.  IF, otoh, mmap_offset allows us change the
> 'viewport' offset, then we need to know what the size of that viewport became.
> 
> It's a goofy semantic altogether.  Either mmap_offset grows a size, or goes away.
> It doesn't matter to me if its a size that the user specifies, or only a return
> value for the size of the available window.
> 
> Bill
> 
> p.s. I'm offline for a day and a half, if you find problems with the largefile
> stuff, sendfile, read, write or seek changes, please feel free to fix them and
> I'll review after they are committed.

-- 
Greg Stein, http://www.lyra.org/