apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Travis <jtra...@covalent.net>
Subject Re: Observations on fragmentation in SMS pools
Date Tue, 10 Jul 2001 03:06:49 GMT
On Tue, Jul 10, 2001 at 01:29:24AM +0200, Luke Kenneth Casson Leighton wrote:
> > > if you examine tdb.c's design, you will notice that apr_table_do()
> > > becomes identical to [but more powerful than] tdb_traverse().
> > > 
> > > 
> > > apr_array_header_t?  again, i haven't thought about it, but
> > > you could likely get away with the same thing.
> > > 
> > 
> > The apr_table_t is just an apr_array_header_t with a specific
> > key/val entry type.
> > 
> > > in other words, i think that supporting apr_pool_t on top of
> > > shared memory (via sms) is going to be tricky: in my opinion,
> > > the apr_pool_xxx() API _and_ the apr_sms_xxx() API can't Deal With
> > > shared memory at a convenient user-acceptable level.
> > > 
> > > HOWEVER!  supporting the data types that apr_pool_xxx() USES
> > > is a different matter.
> > > 
> > > by supporting apr_array_header_t (if possible) and apr_table_t
> > > the complexity of messing about will be hidden from users of
> > > these data types, but they will work quite happily as expected,
> > > even if it's shared memory behind them.
> > > 
> > > what people think?
> > 
> > I think you are in for a ride on this one.  The API for dealing
> > with the tables is currently rather poor, since typically it
> > is casted to an array and then iterated over.  
> 
> implementation?  or usage?
> 
> implementation, i don't know.
> 
> usage?  i think it's _great_!  

Actually both.  The table's have their uses, but really, casting
it to an array and iterating over it?  Ugh!  Table would be
better implemented with a stricter API for setting, fetching, and
iterating.  Of course the case insensitivity also bothers me,
somewhat.

> > The strcasecmp's
> > of the table code are a whole seperate issue.  
> 
> mmm, setn, set, add and addn _are_ a little weird.
> plus, you can't typecast from the const char* to a
> struct* which is what i use it for.
> 
> ... errr.. should i be using apr_hash_t or something? :)

Yes.

> > I would think that
> > the (nearly analagous) apr_hash_t would better suit what you
> > are talking about here.  
>  
> ... mmmm soundss like i should be using apr_hash_t _anyway_.
> will investigate it, get back to you.
> 
> does apr_hash_t have an apr_hash_do()?
> 
> oh YUCK.  it has one of those horrible non-thread-safeable
> dbm-like interfaces.  the _only_ reason that tdb has
> a getfirst/getnext is to make it 'look' like gdbm.
> 
> however, one of the critical things that makes tdb good is
> that it has tdb_traverse(), which - get this: allows you
> to guarantee traversal of *all* nodes, even when you are
> deleting some out from under your nose *simultaneously*.
> 
> 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()?

Nope.

> can you guarantee complete traversal with multiple
> simultaneous adders, deleters, readers and writers?

Nope.  The documentation only dictates that multiple
iterations can go at the same time, and only deleting the
current entry (within an iteration) is well defined.

> and does anyone want a challenge of porting tdb to apr?
> *grin*
> 
> > 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 :)]
> 
> i use it to store the GET/POST args, i use it as a result-table
> for XML-db-like queries, as a table to add nodes to an XML
> doc or to add properties to an XML node, for all _sorts_ of
> horrible things, for which it is ideal.

I would personally advocate switching to the apr_hash_t.  The
table has a linear search (plus strcasecmp), and poor allocation
IMO..

-- Jon


Mime
View raw message