You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Greg Stein <gs...@lyra.org> on 2001/01/02 04:23:36 UTC
Re: cvs commit: apr-util/src/buckets ap_buckets_file.c
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.
Cheers,
-g
On Tue, Jan 02, 2001 at 01:26:54AM -0000, rbb@apache.org wrote:
> rbb 01/01/01 17:26:54
>
> Modified: src/buckets ap_buckets_file.c
> Log:
> Use the same pool to allocate the mmap that was used to create the
> original file.
>
> Revision Changes Path
> 1.18 +3 -1 apr-util/src/buckets/ap_buckets_file.c
>
> Index: ap_buckets_file.c
> ===================================================================
> RCS file: /home/cvs/apr-util/src/buckets/ap_buckets_file.c,v
> retrieving revision 1.17
> retrieving revision 1.18
> diff -u -r1.17 -r1.18
> --- ap_buckets_file.c 2001/01/01 00:33:42 1.17
> +++ ap_buckets_file.c 2001/01/02 01:26:53 1.18
> @@ -53,6 +53,7 @@
> */
>
> #include "apr.h"
> +#include "apr_general.h"
> #include "apr_lib.h"
> #include "apr_file_io.h"
> #include "ap_buckets.h"
> @@ -103,8 +104,9 @@
> /* we need to protect ourselves in case we die while we've got the
> * file mmapped */
> apr_status_t status;
> + apr_pool_t *p = APR_GET_POOL(f);
> if ((status = apr_mmap_create(&mm, f, a->offset, e->length,
> - APR_MMAP_READ, NULL)) != APR_SUCCESS) {
> + APR_MMAP_READ, p)) != APR_SUCCESS) {
> mm = NULL;
> }
> }
>
>
>
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr-util/src/buckets ap_buckets_file.c
Posted by rb...@covalent.net.
> > > hehe... poor example. I use apr_get/set_filedata() :-)
> > >
> > > We've gone this far without the accessor functions. Adding
> > > apr_mmap_from_file would obviate the need.
> >
> > Which doesn't solve the problem. How did you allocate the data? If you
> > used a pool, you have to be careful of which one you used. If you don't
> > get it from the file itself, then you have to pass the pool along with the
> > file.
> >
> > It isn't a question of calling apr_set_userdata. It is a question of
> > which pool was used to allocate the userdata.
>
> Sure sure :-)
>
> But back to the point: the problem at hand is to construct an mmap from a
> file. We have a simple alternative for that.
No, that isn't the problem. The problem at hand is to get access to the
pool within an APR type. An example is to be able to create an mmap from
a file.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apr-util/src/buckets ap_buckets_file.c
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Jan 01, 2001 at 09:53:25PM -0800, rbb@covalent.net wrote:
> > > Try this, you create a file instance. Later, you want to attach userdata
> > > to it. Where do you allocate the data from?
> >
> > hehe... poor example. I use apr_get/set_filedata() :-)
> >
> > We've gone this far without the accessor functions. Adding
> > apr_mmap_from_file would obviate the need.
>
> Which doesn't solve the problem. How did you allocate the data? If you
> used a pool, you have to be careful of which one you used. If you don't
> get it from the file itself, then you have to pass the pool along with the
> file.
>
> It isn't a question of calling apr_set_userdata. It is a question of
> which pool was used to allocate the userdata.
Sure sure :-)
But back to the point: the problem at hand is to construct an mmap from a
file. We have a simple alternative for that.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr-util/src/buckets ap_buckets_file.c
Posted by rb...@covalent.net.
> > Try this, you create a file instance. Later, you want to attach userdata
> > to it. Where do you allocate the data from?
>
> hehe... poor example. I use apr_get/set_filedata() :-)
>
> We've gone this far without the accessor functions. Adding
> apr_mmap_from_file would obviate the need.
Which doesn't solve the problem. How did you allocate the data? If you
used a pool, you have to be careful of which one you used. If you don't
get it from the file itself, then you have to pass the pool along with the
file.
It isn't a question of calling apr_set_userdata. It is a question of
which pool was used to allocate the userdata.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apr-util/src/buckets ap_buckets_file.c
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Jan 01, 2001 at 08:21:56PM -0800, rbb@covalent.net wrote:
>...
> The problem isn't creating an MMAP from the file. That is an example of
> the problem.
It is the only one so far, so I'm suggesting that we don't need the
APR_GET_POOL hack.
>...
> Try this, you create a file instance. Later, you want to attach userdata
> to it. Where do you allocate the data from?
hehe... poor example. I use apr_get/set_filedata() :-)
We've gone this far without the accessor functions. Adding
apr_mmap_from_file would obviate the need.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr-util/src/buckets ap_buckets_file.c
Posted by rb...@covalent.net.
> > > 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
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apr-util/src/buckets ap_buckets_file.c
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Jan 01, 2001 at 08:04:25PM -0800, rbb@covalent.net wrote:
>
> > 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().
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr-util/src/buckets ap_buckets_file.c
Posted by rb...@covalent.net.
> 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.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------