apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: cvs commit: apr-util/src/buckets ap_buckets_file.c
Date Tue, 02 Jan 2001 04:21:56 GMT

> > > Another possible approach (rather than getting the pool) is to have a
> > > function called apr_mmap_from_file() implemented in the file_io subtree. You
> > > can then pull the appropriate pool from the internal file structure and
> > > construct the mmap for that file.
> > 
> > This doesn't solve the general problem that you are allocating data out of
> > a pool, and then you lose access to the pool.
> Hrm. Not sure that I understand the "lose access" part. What I was thinking
> is a function that looks kind of like:
> apr_status_t apr_mmap_from_file(apr_file_t *f, offset, length, flags,
>                                 apr_mmap_t *mm)
> {
>    return apr_mmap_create(mm, f, offset, length, flags, f->pool);
> }
> It might be possible to compute the flags from how we opened "f", so we can
> lose an extra param to apr_mmap_from_file().

The problem isn't creating an MMAP from the file.  That is an example of
the problem.  The problem is that you have just created a structure out of
the pool, and in a later function, it is impossible to get access to the
same pool without passing that pool around.

Try this, you create a file instance.  Later, you want to attach userdata
to it.  Where do you allocate the data from?  It has to be a pool with a
lifetime longer than the file.  If it isn't, then the data may be invalid
when you try to access it.  In a perfect world, the data would be
allocated out of the same pool as the file, but currently that means that
you have to pass that pool around.


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

View raw message