[asterisk-dev] [Code Review] chan_local: Switch from using a random 4 digit hex identifier to an 8 digit sequential hex identifier

[rmudgett]

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

Ship it!


What I was expecting for this patch.

- rmudgett


On Sept. 11, 2012, 1:39 p.m., jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2104/
> -----------------------------------------------------------
> 
> (Updated Sept. 11, 2012, 1:39 p.m.)
> 
> 
> Review request for Asterisk Developers, Mark Michelson and Matt Jordan.
> 
> 
> Summary
> -------
> 
> Prior to this patch, local channel names would look like this:
> 
> Local/exten at context-####;%
> where #### is a four digit hexadecimal number picked completely at random and % is which index of the local channel created as part of that local channel creation event that channel belongs to.
> 
> This changes that to:
> 
> Local/exten at context-########;%
> 
> Where ######## is an eight digit heaxedecimal number picked based on a sequential order from when the channel requested its number. The value is incremented atomically so that the same number can't be grabbed by two parallel threads. This should make overlapping channel names a non-issue as long as we aren't keeping billions of local channels alive at the same time.
> 
> 
> This addresses bug ASTERISK-20318.
>     https://issues.asterisk.org/jira/browse/ASTERISK-20318
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/channels/chan_local.c 372861 
> 
> Diff: https://reviewboard.asterisk.org/r/2104/diff
> 
> 
> Testing
> -------
> 
> Tested channel creation and also what would happen if the value exceeded the storage limit of an unsigned integer.  It just wraps back around. It appears to work identical to how it does with SIP as far as the identifying value is concerned.
> 
> 
> Thanks,
> 
> jrose
> 
>

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