[asterisk-dev] [Code Review]: Fix occasionally incorrectly delayed call-file execution.

[wdoekes]

> On Jan. 25, 2012, 2:09 p.m., wdoekes wrote:
> > I could be wrong, but I think the only thing you're fixing here is that skipping the checking works more reliably.
> > 
> > Before: if next was unset, it would always scan the dir
> > After patch: if next is unset, it won't
> > 
> > In the reporters case, next was always set, so he isn't affected by this fix.
> > My theoretical problem with the granularity of mtime isn't addressed.
> > Although I'm not sure that is the cause of the reporters problem either.
> > 
> > (It would be if another file was also added at t=11:02:59.early, but I don't see any of that. According to his logs, the dir mtime *is* picked up correctly, but the file is simply not found that first time. Unless... if an utime(2) call updates the dir-mtime at t=11:02:59.early, and then the scan is done, new files at t=11:02:59.late would be skipped because then `last` and dir-mtime would be (int)1324029779.)
> 
> rmudgett wrote:
>     You're right.  The fixed skip check will not help.  After reviewing the code again, I am convinced that the problem is the mtime granularity.  Unfortunately, from what I have read, not all systems populate the nanosecond resolution fields with active values or even use the same field names.
>     
>     To fix this for all systems using the old method, would require scanning the directory every second with the resulting increased CPU overhead.

Or.. you could force it to do an extra scan while mtime hasn't changed.

instead of:

if (st.st_mtime == last && (!next || now < next)) continue;

you'd do:

if (st.st_mtime == last && (!next || now < next) && checked_once_more_when_now_GT_last) continue;

// checked_once_more_when_now_GT_last = ((st.st_mtime == last && (!next || now < next)) && now > last);


- wdoekes


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


On Jan. 25, 2012, 8:53 p.m., rmudgett wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1688/
> -----------------------------------------------------------
> 
> (Updated Jan. 25, 2012, 8:53 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Call-files are sometimes delayed incorrectly.
> 
> This is actually a regression that has been in the code since 2007-07-11 (-r74704).  That code restructuring to reduce code indention, incorrectly inverted a test to determine if the spool directory needed to be rescanned.
> 
> Most of the changes to scan_thread() are coding guidelines fixes.
> 
> 
> This addresses bug ASTERISK-19081.
>     https://issues.asterisk.org/jira/browse/ASTERISK-19081
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/pbx/pbx_spool.c 352703 
> 
> Diff: https://reviewboard.asterisk.org/r/1688/diff
> 
> 
> Testing
> -------
> 
> It compiles and I saw that the test was incorrectly inverted during a restructuring.
> 
> 
> Thanks,
> 
> rmudgett
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120126/686af616/attachment.htm>