[Asterisk-Dev] Dev call 1.2 release discussion

[Rich Murphey]

Steve Kann wrote:

> Kristian Nielsen wrote:
>
>> Tzafrir Cohen <tzafrir.cohen at xorcom.com> writes:
>>
>>  
>>
>>>  It appears there's nothing much to do about that. Unless someone can
>>>     suggest and code a useful userspace timing source, the problem 
>>> is here
>>>     to stay for a while
>>>   
>>
>>
>> Is there anything more to it that a thread that does something like 
>> this:
>>
>>  struct pollfd fds[1];
>>  for(;;) {
>>    int timeout = ast_sched_wait(sched);
>>    poll(fds, 0, timeout);
>>    ast_sched_runq(sched);
>>  }
>>
>> with appropriate handlers set up with ast_sched_add()? I guess there
>> must be since it is a problem, so can anyone explain the issues?
>>  
>>
>
> There's nothing really wrong with that -- it's how the scheduling 
> queue is run in chan_iax2 right now, if you don't have zaptel (in the 
> underlying implementation, anyway, where ast_io_wait() calls poll)..
>
> The only thing is that when the system is busy, one can often sleep 
> for much longer (i.e. 100 or 200ms) than you ask for, and the kernel 
> may prefer to wake up a thread that's waiting on io and gets it, as 
> opposed to a thread that's waiting on a timeout, and the timeout expires.
>
> Running the threads with real-time priority, however, seems to be 
> pretty reliable in causing the wakeup to happen on-time much more often.
>
> -SteveK
>

One remaining difference between using wait() and a device is that
interrupts generated by the device can cause the scheduler to
immediately evaluate the priorities and cause the waiting thread to run
immediately, whereas without such event, the scheduler might wait till
the end of the current scheduling time period (quantum) before
evaluating which thread to switch to.

The real time API probably has additional methods that would help.

Cheers,
Rich