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
Is your feature request related to a problem? Please describe.
There may be some inefficiencies / room for improvement in how POSIX is handling the signal masks, that should be evaluated and considered.
For the RT signals, these are masked all the time and timers use sigwait() to synchronously receive them. However that potential to leave stray signals queued. This has been worked around by ensuing that no signals are queued before setting up a timer, but there may be a more efficient way to accomplish this.
Describe the solution you'd like
Consider setting all the unused signals to "IGNORE" such that the kernel will not even deliver them to the process, rather than masking them at the process.
Signal masks are also changed as part of the global lock/unlock procedure what may not be necessary. This should be re-evaluated with the current OSAL design. Historically this may have been necessary for async signals but the current OSAL now avoids async signals for all OSAL-created tasks. Already done in #673/#678
Describe alternatives you've considered
Leave as-is.
Is your feature request related to a problem? Please describe.
There may be some inefficiencies / room for improvement in how POSIX is handling the signal masks, that should be evaluated and considered.
For the RT signals, these are masked all the time and timers use
sigwait()
to synchronously receive them. However that potential to leave stray signals queued. This has been worked around by ensuing that no signals are queued before setting up a timer, but there may be a more efficient way to accomplish this.Describe the solution you'd like
Consider setting all the unused signals to "IGNORE" such that the kernel will not even deliver them to the process, rather than masking them at the process.
Signal masks are also changed as part of the global lock/unlock procedure what may not be necessary. This should be re-evaluated with the current OSAL design. Historically this may have been necessary for async signals but the current OSAL now avoids async signals for all OSAL-created tasks.Already done in #673/#678Describe alternatives you've considered
Leave as-is.
Additional context
See related issue #335
Requester Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: