[asterisk-dev] [Code Review]: Extend the max number of callgroups/pickupgroups

[Thomas Arimont]

> On Aug. 11, 2011, 2:07 a.m., Olle E Johansson wrote:
> > I don't think we should have any compile-time-options or a fixed limit. If we fix this, we should have named pickup groups that can have other attributes as well in the future, possibly using ast_objects. Using bitmaps and numeric matching was something useful when CPUs had less power than today, when people have dual core in their pockets. This patch is just a short-term patch, not the solution to the problem for me.
> 
> amorsen wrote:
>     Personally I believe that the old callgroup/pickupgroup system should be replaced completely by Pickup(@PICKUPMARK) and only remain for backwards compatibility for a while.
>     
>     However, you can have multiple callgroups while one channel can only be assigned to one PICKUPMARK (fortunately Pickup handles 123 at PICKUPMARK&134&PICKUPMARK). If it was possible to add multiple PICKUPMARKs somehow, it would be possible to deprecate callgroups/pickupgroups with no loss of functionality. If we can find someone to do the coding, I can probably find a sponsor for the work :)
>     
>     In the meantime it is difficult to argue against code which is already written. The only objection I have is why not use long or long long? int is 32-bit on all the 64-bit systems supported by Asterisk right now, whereas long is 64-bit on those except on Windows. Long long is 64-bit everywhere even on Windows, at the cost of software emulation on 32-bit.
>     
>

The suggested fix on basis of named groups without a fixed limit is going to make it into Asterisk 11 now.
Please see https://reviewboard.asterisk.org/r/2043 'Extended maximum number of pickupgroups (callgroup/pickupgroup)'


- Thomas


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


On June 22, 2010, 1:22 p.m., raarts wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/466/
> -----------------------------------------------------------
> 
> (Updated June 22, 2010, 1:22 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Currently the number of callgroups/pickupgroups is limited to 63, because the variable type that holds the group bits is a long long.
> 
> Here's a patch that extends this variable to an arbitrary-length (determined at compile time) int array. It currently sets the max number of groups to 1024.
> It implements this for all channels, but I only tested SIP and DAHDI.
> 
> Some people might object to implementing this as an array of ints, because it introduces a loop. But I think call pickups are not done often enough for this to become a problem.
> 
> See https://issues.asterisk.org/view.php?id=16640
> 
> 
> Diffs
> -----
> 
>   /trunk/apps/app_dumpchan.c 271908 
>   /trunk/channels/chan_agent.c 271908 
>   /trunk/channels/chan_dahdi.c 271908 
>   /trunk/channels/chan_gtalk.c 271908 
>   /trunk/channels/chan_jingle.c 271908 
>   /trunk/channels/chan_mgcp.c 271908 
>   /trunk/channels/chan_misdn.c 271908 
>   /trunk/channels/chan_sip.c 271908 
>   /trunk/channels/chan_skinny.c 271908 
>   /trunk/channels/chan_unistim.c 271908 
>   /trunk/channels/misdn_config.c 271908 
>   /trunk/doc/asterisk-mib.txt 271908 
>   /trunk/funcs/func_channel.c 271908 
>   /trunk/include/asterisk/channel.h 271908 
>   /trunk/main/channel.c 271908 
>   /trunk/main/cli.c 271908 
>   /trunk/main/features.c 271908 
>   /trunk/res/snmp/agent.c 271908 
> 
> Diff: https://reviewboard.asterisk.org/r/466/diff
> 
> 
> Testing
> -------
> 
> This patch has been in our asterisk 1.2 for 3 years now without problems. I ported it over to 1.6.2 and tested it there. The patch uploaded here is against trunk which is currently being tested by a colleague of mine, but they are all basically the same patch. 
> 
> 
> Thanks,
> 
> raarts
> 
>

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