| Summary: | ASTERISK-02463: [discuss] Race condition in timed includes | ||
| Reporter: | Tilghman Lesher (tilghman) | Labels: | |
| Date Opened: | 2004-09-25 03:09:05 | Date Closed: | 2011-06-07 14:10:36 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | Because timed includes reevaluate the time for each iteration of the priorities in the dialplan, it is possible for dialplans with timed includes to jump unpredictably (at the specific time that the timed include either begins or ends) between different contexts, possibly even affording a caller special access to the system (i.e. where the jump between contexts transfers the caller to a step following an Authenticate). Note that the companion application, GotoIfTime, does not have this problem, as it evaluates the time condition only once, at the time of execution. ****** ADDITIONAL INFORMATION ****** One possible fix might be to use the time that the call started in all timed includes. This would prevent the context jumping race condition. I'm not sure if this is _the_ solution, however, which why I'm suggesting a discussion. | ||
| Comments: | By: Mark Spencer (markster) 2004-09-25 10:22:12 You can always use a Goto or a Macro to solve something like that. The current behavior is the most accurate. By: Russell Bryant (russell) 2004-09-25 17:42:16 Nothing to port back to the 1.0 branch By: Tilghman Lesher (tilghman) 2004-09-25 20:47:08 While using a Goto or Macro may be an appropriate workaround, it is still a race condition and a bug. We need to either fix it or document that particular race condition, to keep users from making that mistake. Burying a race condition is NOT an appropriate solution. By: Mark Spencer (markster) 2004-09-25 21:16:54 It's not a bug because it's possible that during the call you might want to still do something based on the current time and not the time the call started. You're just assuming that it should be the way you feel it should be in your application. However given that there is already a way to do it the way you want it to behave, and that changing the behavior in the way you suggest precludes the ability to simulate the existing behavior, I would say that it's better just to provide examples of how to use Goto or whatever to influcence behavior. If you want more discussion I suggest you take it back to IRC. | ||