[asterisk-dev] [Code Review]: RFC for proposed astobj2 API container enhancements

[schmidts]

> On March 29, 2012, 9:50 a.m., Mark Michelson wrote:
> > /trunk/include/asterisk/astobj2.h, line 1064
> > <https://reviewboard.asterisk.org/r/1835/diff/1/?file=26924#file26924line1064>
> >
> >     A couple of things:
> >     
> >     1) Does providing a sort_fn imply that the container is sorted? In other words, will every object linked into the container undergo sorting so that it is inserted in the proper spot? Based on the fact there appears to be no ao2_sort() function or anything similar, I'm assuming so. Would there be value to providing a sort_fn but not having the container be automatically sorted? I'm thinking of a case where the order of elements in a container typically does not matter but for the output of a CLI or AMI command, we want to list objects in a particular order.
> >     
> >     2) What does it mean to sort a hash table? Does the sort_fn only apply to items with duplicate keys (i.e. in the same bucket)? The phrase "buckets not sorted" is ambiguous in your parenthetical note.
> 
> rmudgett wrote:
>     The presence of the sort_fn implies that the container is sorted in some manner.  For hash containers this means that the hash buckets are sorted.  Traversing over a hash container still does not give a sorted output of all contents in the container.  Hashing works against sorting.
>     
>     Your normal use case of a container as unsorted but the CLI or AMI output being sorted is the reason for the ao2_container_dup() function.  You duplicate a hash container into a sorted container.  Problems will arise if the contained objects change their search key values when in more than one container.
>     
>     A "sorted" hash container is only useful if you want to use the duplicate object handling options.  However, the degenerate hash container (only one bucket) is a list which has more uses for the sorted property.
>     
>     The same could be said for traversal order over a hash container.  The degenerate hash container has more use for traversal order since it is a list.
>     
>     How is "NULL if buckets not sorted" ambiguous in that context?  I changed the wording to "NULL to not sort the buckets".
> 
> Mark Michelson wrote:
>     The ambiguity of "buckets not sorted" is that I don't know if you mean that the contents within a single bucket is not sorted or if the buckets themselves (somehow) are not sorted. You've answered this with your clarifying comments here indicating that you mean the contents of the individual buckets.

i dont know if this will still brake something but i had once the idea of adding the "move to front" algorithm for objects in a bucket but this had broke some thing in the code. When you are doing a sort order in a bucket it should also be possible to add this move to front method also, right?

Cause this could improve the access speed of objects in a bucket.


- schmidts


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1835/#review5906
-----------------------------------------------------------


On March 29, 2012, 5:06 p.m., rmudgett wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1835/
> -----------------------------------------------------------
> 
> (Updated March 29, 2012, 5:06 p.m.)
> 
> 
> Review request for Asterisk Developers, Mark Michelson and Matt Jordan.
> 
> 
> Summary
> -------
> 
> RFC to add proposed API enhancements for containers.
> 
> API allows for sorted containers, insertion options, duplicate handling options, and traversal order options.
> 
> Also has several documentation corrections.
> 
> 
> Diffs
> -----
> 
>   /trunk/include/asterisk/astobj2.h 360828 
> 
> Diff: https://reviewboard.asterisk.org/r/1835/diff
> 
> 
> Testing
> -------
> 
> It compiles but doesn't link.  This is a RFC.  :)
> 
> 
> Thanks,
> 
> rmudgett
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120330/a02e1ed5/attachment.htm>