[asterisk-dev] [Code Review] Finish implementaton of astobj2 OBJ_MULTIPLE, and convert ast_channel_iterator to use it.

[Russell Bryant]

> On 2009-09-25 18:21:51, Russell Bryant wrote:
> > What would you think about having OBJ_MULTIPLE return an astobj2 container with a single bucket, instead of a linked list of objects?
> 
> Kevin Fleming wrote:
>     That's an interesting concept; then the receiver of that container could use an iterator (or even ao2_find() again) to work with the contents that were returned. I'll think about that and maybe work on it while traveling home.

Also, for the record, Sean Bright originally proposed this idea last year when we were discussing OBJ_MULTIPLE on IRC.  So, I can't take credit for the idea.  ;-)


- Russell


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


On 2009-09-25 12:15:52, Kevin Fleming wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/379/
> -----------------------------------------------------------
> 
> (Updated 2009-09-25 12:15:52)
> 
> 
> Review request for Asterisk Developers and Russell Bryant.
> 
> 
> Summary
> -------
> 
> This patch finishes the implementation of OBJ_MULTIPLE in astobj2 (the case where multiple results need to be returned; OBJ_NODATA mode already was supported). In addition, it converts ast_channel_iterators (only the targeted versions, not the ones that iterate over all channels) to use this method.
> 
> The patch is not yet complete, as astobj2.h needs some editing to document the new structures and remove the existing comments about limitations of OBJ_MULTIPLE, but the functional parts should be complete.
> 
> During this work, I removed the 'ao2_flags' arguments to the ast_channel_iterator constructor functions; there were no uses of that argument yet, there is only one possible flag to pass, and it made the iterators less 'opaque'. If at some point in the future someone really needs an ast_channel_iterator that does not lock the container, we can provide constructor(s) for that purpose.
> 
> 
> Diffs
> -----
> 
>   /trunk/apps/app_chanspy.c 220532 
>   /trunk/apps/app_directed_pickup.c 220532 
>   /trunk/apps/app_softhangup.c 220532 
>   /trunk/funcs/func_channel.c 220532 
>   /trunk/include/asterisk/astobj2.h 220532 
>   /trunk/include/asterisk/channel.h 220532 
>   /trunk/include/asterisk/lock.h 220532 
>   /trunk/main/astobj2.c 220532 
>   /trunk/main/channel.c 220532 
>   /trunk/main/cli.c 220532 
>   /trunk/main/manager.c 220532 
>   /trunk/res/snmp/agent.c 220532 
> 
> Diff: https://reviewboard.asterisk.org/r/379/diff
> 
> 
> Testing
> -------
> 
> None yet; posted this from my hotel room in Madrid, where testing is somewhat hard to do. Will setup a test next week when I return to the office.
> 
> 
> Thanks,
> 
> Kevin
> 
>