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

[Ed Hynan]

> On March 10, 2015, 1:26 p.m., Ed Hynan wrote:
> > /trunk/res/res_timing_kqueue.c, line 240
> > <https://reviewboard.asterisk.org/r/4465/diff/1/?file=71888#file71888line240>
> >
> >     Portability: at least EVFILT_USER and NOTE_TRIGGER are not defined on all kqueue(2) systems.
> 
> Justin T. Gibbs wrote:
>     Which platforms are you referring to?  OS-X added support in 10.6.  Why they haven't updated their man pages is anyones guess:
>     
>     http://www.opensource.apple.com/source/xnu/xnu-1699.24.23/tools/tests/xnu_quick_test/kqueue_tests.c
> 
> Ed Hynan wrote:
>     OpenBSD and NetBSD. These do not have the user event filter.

I adapted a test program so see if uncollected EVFILT_TIMER events can make poll() return -- reliably.
After testing on FreeBSD 9.0 and OpenBSD 5.5 (leaving NetBSD alone unless something seemed promising),
I find that both will fail to return from poll initially; also both can be 'kicked' with a signal or
a EVFILT_READ event -- but the result differs on the two systems, and this is undocumented and almost
certainly undefined behavior and a side effect (and I assume the EVFILT_USER event was just a similar
'kick').

I haven't studied this timing code, so I shouldn't say much, but *if* res_timing_kqueue.c expects to
return a kqueue fd for use with poll, and that poll will wake for EVFILT_TIMER expire events, then
that won't work (judging by the test program trying to do just that).  The technique in res_timing_pthread.c
looks promising: return the read end of a pipe, signal poll by writing a byte, unsignal by consuming
the byte (works in the test), and just using EVFILT_TIMER for the ticks.


- Ed


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


On March 9, 2015, 6:21 p.m., Justin T. Gibbs wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4465/
> -----------------------------------------------------------
> 
> (Updated March 9, 2015, 6:21 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/20150312/9ab275ae/attachment.html>