Notice: We have migrated to GitLab launching 2024-05-01 see here:

#2690 new defect

Unpredictable _POSIX_signals_Send() aka killinfo() behaviour

Reported by: Sebastian Huber Owned by:
Priority: low Milestone: Indefinite
Component: score Version:
Severity: critical Keywords:
Cc: Blocked By:


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()


  • How to account for the timer server resource usage?

Change History (4)

comment:1 Changed on 04/14/16 at 14:18:03 by 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.

comment:2 Changed on 04/15/16 at 05:26:21 by 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.

comment:3 Changed on 05/02/16 at 10:09:20 by Sebastian Huber <sebastian.huber@…>

In [changeset:"66374dfc0c42066fac5f9a62475029711baac735/rtems"]:

posix: Avoid Giant lock in _POSIX_signals_Send()

Update #2555.
Update #2690.

comment:4 Changed on 08/14/17 at 00:50:21 by Chris Johns

Milestone: 5.0Indefinite
Version: 4.10
Note: See TracTickets for help on using tickets.