> > > 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 [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
