Do not block synchronous hardware-generated signals in pc-linux BSP about osal

[skliper]

Imported from trac issue 28. Created by jphickey on 2015-03-18T12:45:46, last modified: 2015-11-20T16:22:16

[skliper]

Trac comment by jphickey on 2015-03-18 13:28:18:

== Additional issue: Realtime signals ==

In the same realm of signal blocking/unblocking - Linux provides several realtime signals for general purpose use by RT applications. These will never be generated by the kernel and will only be sent to a process if explicitly requested by the user or sent from another process via "kill".

The problem is: the global "unblock" which is done after OS_Application_Startup() also unblocks these RT signals from the main thread. This prevents the intended use of these signals if the OSAL/BSP/application had actually designated a thread to receive these signals.

To allow application use of these "RT" signals, they should be blocked by default for all threads including the main thread, so that the implementation is free to unblock them in a secondary thread if desired.

It is OK to leave these blocked in all threads if nothing uses them - they are not delivered unless asked for.

[skliper]

Trac comment by jphickey on 2015-03-18 23:18:29:

This is ready for review, and a relatively straightforward fix.

Branch "trac-28-fix_linux_signal_blocking", commit [changeset:85f586b]

This simply unblocks the hardware-generated signals all the time, and blocks the RT signals all the time so the user-created threads can use them.

[skliper]

Trac comment by jphickey on 2015-04-08 17:13:16:

Setting back to in_work, as I found a problem with the signal blocking as done here when running with the posix OS timers; these are now using RT signals rather than SIGALRM as had been done in a prior OSAL version.

[skliper]

Trac comment by jphickey on 2015-04-14 13:10:38:

The timer issue described earlier is actually resolved as part of Trac #40 -- see commit [changeset:ad447ab] for the specific fix for this.

This commit has been rebased to the (unapproved) 2015-04-14 baseline which includes the above changeset. With this baseline, all unit tests PASS as they should.

The new commit for review is [changeset:bd89ab0]

In addition to unblocking the signals described in the ticket summary, this also moves the unblocking logic from the BSP and into OS_API_Init(). The signal masking requirements in this case are dictated by the operating system, not the specific board. Putting the code here has the benefit of catching all users; masking does not need to be duplicated in pc-linux, pc-cygwin, mac-osx, or the cFS PSP, and they will all be consistent.

[skliper]

Trac comment by glimes on 2015-05-18 20:24:58:

Recommend accept, based on commit [changeset:ef0726a].

[skliper]

Trac comment by sduran on 2015-06-01 12:09:26:

Recommend accept. Will need to make the same changes made in bsp/pc-linux/src/bsp_start.c, in the pc-linux PSP cfe_psp_start.c file.

[skliper]

Trac comment by acudmore on 2015-06-01 13:58:50:

Recommend accept.

[skliper]

Trac comment by jphickey on 2015-06-16 16:45:39:

== CHANGE SET HAS BEEN REBASED ==

To allow this change set to move forward I have rebased it to the latest {{{development}}} branch that was just approved during the 2015-06-16 CCB meeting.

Reviews should be based on commit [changeset:3e05c66]

The prior commit (in [comment:7]) is based off a merge that included #40 but this is still in a state of flux. Please disregard prior commit IDs listed in this thread. Note that the //content// is identical between these commits, the only change is where it lies within the git history.

[skliper]

Trac comment by jwilmot on 2015-06-30 11:26:21:

Recommend accept

[skliper]

Trac comment by glimes on 2015-06-30 14:40:55:

CCB approved.