Initial Signal Mask Incompatability

Joel Sherrill joel at
Mon Sep 9 22:17:11 UTC 2019


In porting some user code to RTEMS, I have discovered that RTEMS does
not agree with Linux, FreeBSD, or Cygwin on the initial state of the
signal mask. POSIX appeared to be ambiguous
so I I checked with another RTOS kernel developer I know through FACE
who has decades of
POSIX experience.

I now have a stand alone test program and an RTEMS patch to make RTEMS match the
other POSIX OSes I tried. I need to write an RTEMS psxtest to confirm
the desired behavior.

I will file this as a ticket but devel is having issues so am starting
the discussion here.

There are some subtle rules which need to be followed for
the value of the created thread's signal mask. Because signals
are part of C99 and enhanced by POSIX, both Classic API tasks
and POSIX threads have to have them enabled.

(1) Internal system threads should have no signals enabled. They
have no business executing user signal handlers -- especially IDLE.

(2) The initial signal mask for other threads needs to follow the
implication of a pure C99 environment which only has the methods
raise() and signal(). This implies that all signals are unmasked
until the thread explicitly uses a POSIX methods to block some.
This applies to both Classic tasks and POSIX threads created
as initialization tasks/threads (e.g. before the system is up).

(3) After the initial threads are created, the signal mask should
be inherited from the creator. This can be done based on system state.


(1) The default signal mask does not matter for any application that
does not use POSIX signals.

(2) It is assumed that Classic API tasks should provide a compliant
C run-time environment. Hence the default signal mask state matters.

Once I tidy up my patch, I will submit it. I would really like to have a ticket
to track this because it is a change in behavior that (however unlikely)
could impact a user.


More information about the devel mailing list