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

[rmudgett]

> 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.
> 
> wdoekes wrote:
>     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);

Well, what do you know.  I came in this morning with the idea to do something just like that. :)


- rmudgett


-----------------------------------------------------------
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/528b899e/attachment.htm>