[asterisk-dev] bweschke: branch 1.4 r150816 - /branches/1.4/main/manager.c
bweschke at gmail.com
Sun Oct 19 20:48:17 CDT 2008
Russell Bryant wrote:
> On Oct 17, 2008, at 8:42 PM, SVN commits to the Digium repositories
>> Author: bweschke
>> Date: Fri Oct 17 20:42:23 2008
>> New Revision: 150816
>> URL: http://svn.digium.com/view/asterisk?view=rev&rev=150816
>> Using the GetVar handler in AMI is potentially dangerous (insta-
>> crash [tm]) when you use a dialplan function that requires a channel
>> and then you don't provide one or provide an invalid one in the
>> Channel: parameter. We'll handle this situation exactly the same way
>> it was handled in pbx.c back on r61766. We'll create a bo
>> gus channel for the function call and destroy it when we're done. If
>> we have trouble allocating the bogus channel then we're not going to
>> try executing the function call at all and run the risk of crashing.
> I do not have a direct problem with this change, because it is the
> correct thing to do if dialplan functions are allowed to assume a
> channel is present.
> However, I'd like to propose that for the sake of performance, we
> handle this the opposite way. How about we make it so that dialplan
> functions are _not_ allowed to assume that a channel will be present.
> For any function that _must_ have a channel to do something useful
> (like the CHANNEL() function!), just make it return an error if no
> channel is provided.
When we talk about "the sake of performance" it really comes down to
where the performance hit actually is, no ?
With the current patch, we only take on the hit on performance on the
execution of a manager GetVar action when it's determined that the
varname is likely a function. If we move this logic into the guts of
ast_func_read proper, isn't that a much larger creep on the scope of
that performance hit?
Bird's The Word Technologies, Inc.
More information about the asterisk-dev