You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
As part of the global lock the POSIX implementation is setting the signal mask of the parent process. However, the signal mask which is being set is the same mask that was already set in the parent process during the initialization.
To Reproduce
N/A
Expected behavior
The signal mask is already configured during initialization, so it should not be re-configured when locking/unlocking the global object tables.
Additional context
I have investigated and I cannot find any justification for this anymore. In older versions of OSAL the signal(s) were not blocked and therefore e.g. SIGINT, SIGALRM etc could be handled by any thread. In this design it was likely important to make sure that a timer/interrupt doesn't get processed while internal OSAL ops are being performed.
But In the current OSAL design all of these signals are blocked initially in the main task - which all normal tasks then inherit. So this is only resetting the same mask that was already configured.
Reporter Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered:
Removes the signal mask updates from the POSIX global lock (not needed).
Adds a condition variable to the structure, which can be used to
directly wake up a waiting task rather than requiring that task to poll
the global state.
Removes the signal mask updates from the POSIX global lock (not needed).
Adds a condition variable to the structure, which can be used to
directly wake up a waiting task rather than requiring that task to poll
the global state.
Describe the bug
As part of the global lock the POSIX implementation is setting the signal mask of the parent process. However, the signal mask which is being set is the same mask that was already set in the parent process during the initialization.
To Reproduce
N/A
Expected behavior
The signal mask is already configured during initialization, so it should not be re-configured when locking/unlocking the global object tables.
Code snips
Locking:
osal/src/os/posix/src/os-impl-idmap.c
Line 98 in fa0cffa
Unlocking:
osal/src/os/posix/src/os-impl-idmap.c
Line 149 in fa0cffa
System observed on:
Ubuntu 20.04
Additional context
I have investigated and I cannot find any justification for this anymore. In older versions of OSAL the signal(s) were not blocked and therefore e.g. SIGINT, SIGALRM etc could be handled by any thread. In this design it was likely important to make sure that a timer/interrupt doesn't get processed while internal OSAL ops are being performed.
But In the current OSAL design all of these signals are blocked initially in the main task - which all normal tasks then inherit. So this is only resetting the same mask that was already configured.
Reporter Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: