[asterisk-dev] ast_channel_search_locked for CEL

[Steve Murphy]

On Wed, 2008-11-05 at 08:46 -0800, Brian Degenhardt wrote:
> Renaming the topic for a bit.
> 
> Tim Panton wrote:
> > On 4 Nov 2008, at 23:54, Brian Degenhardt wrote:
> >>
> >> That's what I was thinking, but I was wondering if Murf and Russell
> >> could comment on if that approach is adequate, or if we want to  
> >> maintain
> >> a hashtab of channels keyed on linkedid, and insert/remove them from  
> >> there.
> >>
> >> I'm sorta partial to your way, above.  While it's slower, we don't  
> >> have
> >> to worry about maintaining the separate data structure which has the
> >> potential to get out of sync.  Especially since this code only runs if
> >> you care about LINKEDID_END events.
> > 
> > I've been so long out of the C world I'm not sure this helps, but we
> > had a similar problem _years_ ago and I ended up solving it with a weird
> > dual purpose data structure. It was (originally) a linked list the  
> > sequence
> > mattered and in some cases it needed to be walked in order.
> > The most frequent access was a name based lookup that was independent
> > of sequence for which we really wanted a hashtable.
> > 
> > What we did was to replace the 'malloc/free' code in the linked list  
> > insert/delete.
> > It allocated a slot in a hash table (based on a hash of the name). All  
> > the
> > list walk stuff worked exactly as before, but we added a fast  
> > find_by_name()
> > that used the hashtable. It gave us a huge speedup. The only problem  
> > was when
> > the names changed. - we had to implement that as a delete/add.
> 
> The problem isn't really how do we implement this search in a fast way.
>  If speed was our only concern I'd be off to the races designing a fast
> data structure to solve this problem.
> 
> However, we have to weigh this against maintainability, and
> defensiveness against bugs.  If the LINKEDID_END operation is barely
> used, and if it doesn't really contribute to the overall load of a
> system, the ideal solution would be the one with the smallest code
> footprint.
> 
> The fact that Sean Bright can paste in the solution in a few lines of
> code using ast_channel_search_locked is a pretty good vote for that
> approach.  Especially, as Russell says, when we switch to refcounts to
> make this operation even faster.

Brian-- 

I agree.

murf

-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20081106/c0cffcbe/attachment.bin