Unpredictable _POSIX_signals_Send() aka killinfo() behaviour

[Sebastian Huber]

The _POSIX_signals_Send() iterates over all threads in the system without protection of the object allocator lock. At least on SMP systems this may lead to unpredictable behaviour. Since _POSIX_signals_Send() is called from interrupt context in the alarm() and ualarm() timers, this function may lead to long interrupt processing times.

Suggested solution:

• Forbid _POSIX_signals_Send() in interrupt context.
• Properly protect iteration over all threads with the object allocator mutex.
• Use timer server for alarm() and ualarm()

Question:

• How to account for the timer server resource usage?

[Joel Sherrill]

What resources need to be accounted for?

And POSIX timers also need to be able to fire signals. Those are not on your list but currently run in the tick ISR.

[Sebastian Huber]

Maybe we need a POSIX internal timer server.

Alternatively, we need more sophisticated data structures to speed up the job done potentially in interrupt context. This is likely in conflict with the desire to always enable the POSIX API, e.g. a lot more memory in the thread control block or uses some sort of dynamic memory.

[Sebastian Huber <sebastian.huber@…>]

In 66374dfc0c42066fac5f9a62475029711baac735/rtems:

posix: Avoid Giant lock in _POSIX_signals_Send()

Update #2555.
Update #2690.