ap_hash_t and userdata (was: Re: filtering patches)

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

On Mon, Jul 10, 2000 at 02:01:21PM -0400, Rodent of Unusual Size wrote:
>...
> If we had tables
> with binary values (Dirk?), dealing with this would be simple.
> All a filter has to do is hang some sort of pointer to the pool
> off the request_rec.  That could be done now, in a messy kludgy
> fashion.

"tables with binary values" can be handled by Tony's new ap_hash_t APIs (see
apr_hash.h). It is a true hash table, too, unlike ap_table_t which is
implemented as a linear scan.

"hanging pointers" can be handled with ap_set_userdata(data, key, cleanup,
r->pool).

I'm using the tables in the DAV code to map URIs to unique integers.

hmm. Should ap_table_t be reimplemented as cover/utility functions on
ap_hash_t?

Cheers,
-g

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

Re: ap_hash_t and userdata (was: Re: filtering patches)

[Tony Finch <do...@dotat.at>]

gstein@lyra.org wrote:
>
>hmm. Should ap_table_t be reimplemented as cover/utility functions on
>ap_hash_t?

See STATUS:

    * Replace tables with a proper opaque ADT that has pluggable
      implementations (including something like the existing data type,
      plus hash tables for speed, with options for more later).
	Status: fanf is working on this.

Tony.
-- 
f.a.n.finch    fanf@covalent.net    dot@dotat.at
471 scraping the roe from the slit-open belly of comedy