[asterisk-dev] [Code Review] Properly handle the linkedid for local channels and fix race condition for LINKEDID_END CEL event.

[Terry Wilson]

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

(Updated May 2, 2012, 10:23 a.m.)


Review request for Asterisk Developers and Mark Michelson.


Changes
-------

1) Improve a comment
2) Even if CHAN_START isn't being reported on, make sure we still track for LINKED_END if necessary
3) Move the bridged peer code down past a bunch of failure cases that don't have anything to do with the peer to simplify returning on error
4) Unref linkedids when appropriate and combine the do_reload and cli_register into a single if since we do the same thing for failures in both


Summary
-------

While writing CEL tests, I noticed that if there is no requestor channel that the ;1 and ;2 sides of a local channel would have different linkedids when they should be the same. After fixing that issue, I found that Local channels were hung up so close together that the time between unlinking and destroying the channel would cause a race condition giving me 0, 1, or 2 LINKEDID_END events based on when they were unlinked.

This patch has the ;2 channel inherit the linkedid of the ;1 channel and fixes the race condition by no longer scanning the channel list for "other" channels with the same linkedid. Instead, cel.c has an ao2 container of linkedid strings and uses the refcount of the string as a counter of how many channels with the linkedid exist. Not only does this eliminate the race condition, but it also allows us to look up the linkedid by the hashed key instead of traversing the entire channel list.


Diffs (updated)
-----

  /branches/1.8/channels/chan_local.c 365004 
  /branches/1.8/main/cel.c 365004 

Diff: https://reviewboard.asterisk.org/r/1895/diff


Testing
-------

Ran through the dialplan in the cdr/cdr_accountcode testsuite test and tested a single-channel call. Only one linkedid appeared, no refcount errors.


Thanks,

Terry

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