Hi Sebastian and Clark, The explanations make sense to me. I now understand some of the limitations of POSIX timers and I'll probably rework to use clock_nanosleep() instead. Thanks for your help, mh On Wed, Jun 28, 2023 at 2:42 AM Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote: > > On 2023-06-27 18:22:51 [+0000], Clark Williams wrote: > > Martin, > Hi, > > > Building on what Sebastian said, I'd say you have two options for this. The > > first, if you absolutely must use POSIX timers, is to bump the ktimer/* > > threads to a SCHED_FIFO priority at least one above your application. That > > Be ware that this thread also handles all _other_ wakeup on the given > CPU. > … > > Ever since we've been using the PREEMPT_RT series, most people avoid using > > signals for regular event delivery. It's not that the signal mechanism is > > wrong, it's just that it's complicated code, having to handle a lot of > > legacy signal handling behavior that an RTOS probably doesn't care about. I > > suspect that after PREEMPT_RT merges, we'll need to do a thorough audit, to > > make sure we don't have any corner cases for unreasonable delays in signal > > delivery, but to this point it hasn't really been a priority. > > Other than the locks, you have a memory allocation in the sender's path. > > > If it were me I'd do it in a dedicated thread. > > Either that or rework the logic so that the proper thread gets the > wakeup. > > > Clark > > Sebastian
