[asterisk-dev] [Code Review] 4465: Update the kqueue timing module to conform to current timer API.

Matt Jordan reviewboard at asterisk.org
Sun Mar 15 22:18:26 CDT 2015


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


Thanks for the patch - there's a few other kqueue related issues floating around out there that this patch may help address.

I didn't review this for correctness, merely for coding guideline violations. Assuming someone else who can run res_timing_kqueue can confirm that it works and that the tests pass, I'll be happy to Ship It! once the guidelines are cleaned up.


/trunk/res/res_timing_kqueue.c
<https://reviewboard.asterisk.org/r/4465/#comment25245>

    For structure packing, you may want to declare this as:
    
    struct kqueue_timer {
        int handle;
        intptr_t period;
    #ifndef EVFILT_USER
        int continuous_fd;
        unsigned int contuous_fd_valid:1;
    #endif
        unsigned int is_continuous:1;
    }



/trunk/res/res_timing_kqueue.c
<https://reviewboard.asterisk.org/r/4465/#comment25244>

    Nitpick: in the Asterisk project, we don't place the return type of the function or its scope on a separate line.
    
    You can check out the coding guidelines here:
    
    https://wiki.asterisk.org/wiki/display/AST/Coding+Guidelines



/trunk/res/res_timing_kqueue.c
<https://reviewboard.asterisk.org/r/4465/#comment25246>

    Just use ast_debug(X, ...) here.
    
    Since this appears to be a pretty 'low level' debug message, a debug level of 5 is probably appropriate.



/trunk/res/res_timing_kqueue.c
<https://reviewboard.asterisk.org/r/4465/#comment25247>

    And ast_debug(5, ...); here as well



/trunk/res/res_timing_kqueue.c
<https://reviewboard.asterisk.org/r/4465/#comment25248>

    ast_debug(5, ...); here as well 



/trunk/res/res_timing_kqueue.c
<https://reviewboard.asterisk.org/r/4465/#comment25249>

    ast_debug(5, ...); here


- Matt Jordan


On March 12, 2015, 9:07 p.m., Justin T. Gibbs wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4465/
> -----------------------------------------------------------
> 
> (Updated March 12, 2015, 9:07 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24857
>     https://issues.asterisk.org/jira/browse/ASTERISK-24857
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Update the kqueue timing module to conform to current timer API.
> 
> This fixes issues with using the kqueue timing source on Asterisk 13
> on FreeBSD 10.
> 
> res_timing_kqueue.c:
> 	Remove support for kevent64().  The values used to support Asterisk
> 	timers fit within 32bits and so can be handled on all platforms via
> 	kevent().
> 
> 	Provide debug logging for, but do not track, unacked events.  This
> 	matches the behavior of all other timer implementations.
> 
> 	Implement continuous mode by triggering and leaving active, a user
> 	event.  This ensures that the file descriptor for the timer returns
> 	immediately from poll(), without placing the load of a high speed
> 	timer on the kernel.
> 
> 	In kqueue_timer_get_max_rate(), don't overstate the capability of
> 	the timer.  On some platforms, UINT_MAX is greater than INTPTR_MAX,
> 	the largest integer type kqueue supports for timers.
> 
> 	In kqueue_timer_get_event(), assume the caller woke up from poll()
> 	and just return the mode the timer is currently in.  This matches
> 	all other timer implementations.
> 
> 	Adjust the test code now that unacked events are not tracked.
> 
> 
> Diffs
> -----
> 
>   /trunk/res/res_timing_kqueue.c 432637 
> 
> Diff: https://reviewboard.asterisk.org/r/4465/diff/
> 
> 
> Testing
> -------
> 
> Asterisk 13.2.0 on FreeBSD 10-stable: "timing test", pjsip incoming/outgoing calls, voicemail prompts and recordings.  All of the above failed without these changes.
> 
> 
> Thanks,
> 
> Justin T. Gibbs
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150316/69d64c2e/attachment-0001.html>


More information about the asterisk-dev mailing list