POSIX timers misbehaviour

[Daniel Krüger]

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.

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

[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 make 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 ?

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

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

[Gedare Bloom]

bump milestone

[Gedare Bloom]

adjust from 5.0 to 4.11.1

[Daniel Krüger]

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