On Mon, Jul 09, 2001 at 04:50:31PM -0700, [EMAIL PROTECTED] wrote: > > > cool, huh? [and it's only 1024 LOC yes i know it's not > > portable like APR i was v.impressed that someone actually > > looked at it when i first mentioned it here, btw ] > > > > so *grin*. > > > > can you guarantee thread-safety on apr_hash_t using > > apr_hash_first()/next()/this()? > > > > can you guarantee complete traversal with multiple > > simultaneous adders, deleters, readers and writers? > > > > and does anyone want a challenge of porting tdb to apr? > > *grin* > > Challenge, did somebody say challenge? I'm always up for a challenge. > :-) > > > > BTW: Why are tables in APR at all? The only thing I see used > > > is headers in apr-util hooks code, and in the xml, but that of > > > course can be fixed. Step 1, remove tables from APR, Step 2, > > > remove tables from Apache. > > > > agh! tables are kinda... entrenched into xvl. okay, maybe > > not: only 10 instances of apr_table_make. 10 of apr_table_do > > [which is why i was advocating it: i really like it :)] > > Tables are in APR, because were originally moved from Apache to APR before > APR-util existed. They should really move to apr-util. They should never > be removed from Apache. Tables are useful because they garuantee a > general order to the data, namely, the order you insert information into > the table. Hashes have a different use case.
Tables should definitely be moved to APR-util if they are to remain. As for Apache, there are better structures that dictate general order than the table. IMNSHO, the only reason tables are still in Apache is inertia. Nobody wants to go through and change everything to a more sane data structure. Case insensitive searches -- linear search time over the table ... ugh. -- Jon
