#2607 assigned defect

timer_getoverrun() implemetation violates POSIX

Reported by: Sebastian Huber Owned by: Needs Funding
Priority: normal Milestone: Indefinite
Component: unspecified Version: 4.10
Severity: normal Keywords:
Cc: Blocked By:
Blocking:

Description

The timer_getoverrun() implementation has little to do with the POSIX specification.

In _POSIX_Timer_TSR() signals are send via pthread_kill() in ISR context, thus no signal handlers are run.

Change History (5)

comment:1 Changed on Feb 22, 2016 at 2:06:47 PM by Joel Sherrill

I haven't looked into the timer_getoverrun() yet but it was on my list.

I don't see the problem with _POSIX_Timer_TSR(). Yes it runs in ISR context and there is no current thread context. But it sends a signal to a specified thread which is OK. If it sent it to pthread_self(), it would be broken.

if ( pthread_kill ( ptimer->thread_id, ptimer->inf.sigev_signo ) ) {

The evaluation of the impact of that signal should be deferred to the end of the ISR as part of the ISR dispatch and post switch processing.

comment:2 Changed on Feb 22, 2016 at 2:12:04 PM by Sebastian Huber

The ptimer->thread_id might be not equal to executing->Object.id, thus the overrun = 0 makes no sense right after the pthread_kill().

comment:3 in reply to:  2 Changed on Feb 22, 2016 at 4:01:17 PM by Joel Sherrill

Replying to sebastian.huber:

The ptimer->thread_id might be not equal to executing->Object.id, thus the overrun = 0 makes no sense right after the pthread_kill().

OK. That makes sense. Doesn't really match your initial comment though.

I am not sure how to tie the resetting of the overrun counter with the actual execution of the signal handler. There can be 0-n timers associated with a single signal.

comment:4 Changed on Jan 26, 2017 at 7:16:00 AM by Sebastian Huber

Milestone: 4.11.14.11.2

comment:5 Changed on Feb 15, 2017 at 1:37:51 PM by Sebastian Huber

Milestone: 4.11.2Indefinite
Owner: set to Needs Funding
Status: newassigned
Note: See TracTickets for help on using tickets.