[asterisk-bugs] [Asterisk 0017742]: [patch] ast_sched_runq runs to much events if one event runs too long

Asterisk Bug Tracker noreply at bugs.digium.com
Thu Jul 29 11:54:28 CDT 2010


The following issue has been UPDATED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17742 
====================================================================== 
Reported By:                schmidts
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17742
Category:                   Core/General
Reproducibility:            sometimes
Severity:                   minor
Priority:                   normal
Status:                     ready for testing
Asterisk Version:           1.6.2.10 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-07-28 16:57 CDT
Last Modified:              2010-07-29 11:54 CDT
====================================================================== 
Summary:                    [patch] ast_sched_runq runs to much events if one
event runs too long
Description: 
same in 1.8.0
after debugging and tracing the new heap schedule concept i´ve found
something iam not sure about if this works like expacted.
in sched.c in the ast_sched_runq there is a for loop which takes the next
event from the heap and calculate the time which is 1 ms in future make a
time compare if this event is between now and the calculated time. if not
it breaks and get back to do_monitor. 
If it founds an event it start the callback and release this event then
take the next event and does the time calc and compare again.
if the callback of the curent event tooks to much time, or there are too
many events the time compare could get events which allready 1 ms further
away than expacted. 
they have been 2 ms or more away at the start time of runq.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-07-29 11:54 lmadsen        Description Updated                          
2010-07-29 11:54 lmadsen        Additional Information Updated                  
 
======================================================================




More information about the asterisk-bugs mailing list