> 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
> 
>

-- 
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Reply via email to