[asterisk-dev] ast_channel_search_locked for CEL
bmd at digium.com
Wed Nov 5 10:46:58 CST 2008
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
>> a hashtab of channels keyed on linkedid, and insert/remove them from
>> I'm sorta partial to your way, above. While it's slower, we don't
>> 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
> 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
> It allocated a slot in a hash table (based on a hash of the name). All
> list walk stuff worked exactly as before, but we added a fast
> 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
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.
More information about the asterisk-dev