#2228 assigned defect

POSIX timers misbehaviour

Reported by: Daniel Krüger Owned by: Needs Funding
Priority: normal Milestone: Indefinite
Component: score Version: 4.10
Severity: normal Keywords: posix timer
Cc: Blocked By:
Blocking:

Description

I discovered some differences of the POSIX timer behaviour in RTEMS in respect to Linux. I don't know what the POSIX standard says in that regard.

I adapted the RTEMS POSIX timers implementation to match Linux a little bit more. The patches for RTEMS are provided as attachment.

Change History (14)

comment:1 Changed on Dec 17, 2014 at 12:48:56 PM by Sebastian Huber

POSIX is pretty clear in this regard:

http://pubs.opengroup.org/onlinepubs/009695399/functions/timer_create.html

It is a per-process timer, so the current RTEMS implementation is not conformant with the POSIX requirements. The question is whether this is a bug or a feature. If we change the behaviour then we may break existing RTEMS applications. I am in favour of enforcing POSIX strictly.

comment:2 Changed on Dec 17, 2014 at 10:10:20 PM by Chris Johns

This is a bug in RTEMS because pthreads has been clear from the start a signal is per-process and delivered to the process. What this means in RTEMS is made complicated because we have different thread domains, the classic and POSIX.

I am currently not happy with this change being merged for 2 reasons.

First a brief inspection of the kill code to check if it is ok to call from an isr shows _POSIX_signals_Vectors being check before disabling dispatching. Is this ok ? The sigaction code has protected references.

Second the kill call hits all threads in the system including classic threads and here I am concerned classic API tasks could assume no POSIX support enabled and therefore no signals and so no handling for an unexpected signal. Further this code will not have any support for pthread sigmasks and so it will not be able to manage signals in the same way pthread code should. Should kill be hitting all threads ? This makes sense from the kill call point of view so should there exist a means to deliver a signal to only the POSIX threads ?

Oh and why does a getpid check happen at the start of kill ? Are we expecting another pid to ever exist ?

Last edited on Dec 17, 2014 at 10:11:09 PM by Chris Johns (previous) (diff)

comment:3 Changed on Dec 17, 2014 at 10:44:37 PM by dufault

In general I agree with Chris:

  • I haven't looked at the check to see if it is OK to call from an ISR so I won't comment.
  • kill shouldn't signal classic threads. I don't use them, but if I did, I wouldn't expect that to change. POSIX and classic are orthogonal, there is no reason to extend POSIX behavior to classic behavior.
  • Go ahead and check getpid(). Who knows what will happen in the next RTEMS iteration? PID per core someday?

comment:4 in reply to:  2 Changed on Dec 18, 2014 at 8:49:04 AM by Daniel Krüger

Replying to chrisj:

First a brief inspection of the kill code to check if it is ok to call from an isr shows _POSIX_signals_Vectors being check before disabling dispatching. Is this ok ? The sigaction code has protected references.

I cannot comment on this, because I don't understand the RTEMS internals regarding this matter.

Second the kill call hits all threads in the system including classic threads and here I am concerned classic API tasks could assume no POSIX support enabled and therefore no signals and so no handling for an unexpected signal. Further this code will not have any support for pthread sigmasks and so it will not be able to manage signals in the same way pthread code should. Should kill be hitting all threads ? This makes sense from the kill call point of view so should there exist a means to deliver a signal to only the POSIX threads ?

According to cpukit/posix/src/pthread.c:_POSIX_Threads_Create_extension() classic threads are configured so that all POSIX signals are blocked. Hence killinfo() won't deliver any POSIX signal to a classic thread. Furthermore killinfo() has support for pthread sigmask. It is stored in api->signals_blocked.

Oh and why does a getpid check happen at the start of kill ? Are we expecting another pid to ever exist ?

I was surprised too about this check. I think currently it will never fail.

comment:5 Changed on Mar 2, 2015 at 8:50:26 PM by Gedare

Milestone: 4.115.0

bump milestone

comment:6 Changed on Mar 2, 2015 at 8:50:59 PM by Gedare

Milestone: 5.04.11.1

adjust from 5.0 to 4.11.1

comment:7 Changed on Apr 9, 2015 at 2:48:05 PM by Daniel Krüger

What is the status of this bug report?
What is required to get the patches mainline?

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

Milestone: 4.11.14.11.2

comment:9 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.