apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <l...@samba-tng.org>
Subject Re: Observations on fragmentation in SMS pools
Date Mon, 09 Jul 2001 23:29:24 GMT
> > 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_!  

> 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? :)

> 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()?

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*

> 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.


Mime
View raw message