[asterisk-dev] [Code Review] Use kqueue(2) to reduce CPU consumption in *BSD and Mac OS X

[Mark Michelson]

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

Ship it!


If this is still compiling on OS X and the various BSDs, I'd say this is good to go. Good work, Tilghman!

- Mark


On 2010-03-30 09:48:12, Tilghman Lesher wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/543/
> -----------------------------------------------------------
> 
> (Updated 2010-03-30 09:48:12)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Currently, we use inotify(2), which is a Linux-only kernel API, to check as to whether timezone files have changed, which allows an admin to change the machine timezone on the fly, and we will reparse it.  The alternative currently is for us to sit in what is essentially a busy loop, checking whether a timezone file is changed.  For most situations, these files change very seldom, so this represents quite a bit of CPU consumption over the life of a process.
> 
> The BSDs (and Mac OS X) contain a similar interface, called kqueue(2).  This has been implemented for timezone files, which should conserve CPU usage while running Asterisk on those platforms.
> 
> 
> Diffs
> -----
> 
>   /trunk/Makefile 255321 
>   /trunk/build_tools/menuselect-deps.in 255321 
>   /trunk/configure UNKNOWN 
>   /trunk/configure.ac 255321 
>   /trunk/include/asterisk/autoconfig.h.in 255321 
>   /trunk/main/stdtime/localtime.c 255321 
>   /trunk/pbx/pbx_spool.c 255321 
>   /trunk/res/res_timing_kqueue.c PRE-CREATION 
>   /trunk/tests/test_time.c 255321 
> 
> Diff: https://reviewboard.asterisk.org/r/543/diff
> 
> 
> Testing
> -------
> 
> Now works on Mac OS X 10.6.2.  Succeeds against unit test!!!
> 
> 
> Thanks,
> 
> Tilghman
> 
>