[Asterisk-code-review] app_waitforcond: New application (asterisk[16])

N A asteriskteam at digium.com
Mon May 24 12:27:37 CDT 2021


N A has posted comments on this change. ( https://gerrit.asterisk.org/c/asterisk/+/15928 )

Change subject: app_waitforcond: New application
......................................................................


Patch Set 1:

> Patch Set 1:
> 
> > Patch Set 1:
> > 
> > > Patch Set 1:
> > > 
> > > What are actual real world use cases for this? It feels like this is taking dialplan into some sort of external manipulation cross synchronization weird area.
> > 
> > There's no manipulation at all of anything. I wrote it as an optimization to some of my existing dialplan code.
> > 
> > For instance, suppose you have:
> > same => n(loop),GotoIf($["${somesetofconditions}"="1"|"${somethingelse}"="42"]?dosomething)
> > same => n,Wait(0.1)
> > same => n,Goto(loop)
> > 
> > Well, now the Asterisk CLI is a mess with any verbosity at least 3.
> > 
> > I try to avoid polling like this as much as possible, using ChannelRedirect instead, but in some cases, this kind of behavior is needed and it would be very useful to just have an application that waits for some amount of time or until some condition(s) are true.
> > 
> > It doesn't enable anything new per se, it's just a much cleaner and more efficient way to do that, and a generic Wait function unlike the existing functions which are very specific (e.g. WaitUntil, which is for time only, or WaitForRing, which is for ring only). This is just an ultra-generic version of that.
> 
> What are some real world example conditions?

Such as if you need to wait for a small amount of time for something to happen on another channel. That channel might set a SHARED variable (or GLOBAL, just something that's globally readable), and then the polling channel might do something. Except, there might be multiple channels that could be in this state, and the channel that sets the variables doesn't know what channels are waiting for that event to occur, so ChannelRedirect doesn't work so well. Then, consider there could be multiple channels checking for different conditions and such elsewhere in the dialplan. There really isn't a clean way of using ChannelRedirect, polling works since we're not doing it for very long, maybe a few seconds, but whenever the condition is true, we'd like to do something immediately. But this makes a mess in the CLI, so this is a cleaner and more efficient way to do that. I have maybe a dozen of these in my dialplan that I'm replacing with this application. I know others who use similar polling techniques and would benefit from it as well.


-- 
To view, visit https://gerrit.asterisk.org/c/asterisk/+/15928
To unsubscribe, or for help writing mail filters, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: 16
Gerrit-Change-Id: I08adf2824b8bc63405778cf355963b5005612f41
Gerrit-Change-Number: 15928
Gerrit-PatchSet: 1
Gerrit-Owner: N A <mail at interlinked.x10host.com>
Gerrit-Reviewer: Friendly Automation
Gerrit-CC: Joshua Colp <jcolp at sangoma.com>
Gerrit-Comment-Date: Mon, 24 May 2021 17:27:37 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20210524/b493b756/attachment.html>


More information about the asterisk-code-review mailing list