I was refering to the wait for the signal on the worker thread, which would simply be waiting on a semaphore/condition variable which indicates work (pending notification) is available.
See here for how I changed how nimBLE uses SIGEV_THREAD due to the aforementioned issue: https://github.com/apache/mynewt-nimble/blob/241911bd02b9bd3445f0194dab4539281fa3f849/porting/npl/nuttx/src/os_callout.c In this case I'm using a condition variable. Any signals which are not desired from the thread can be masked, so no reason for it to be interrupted. Best, Matias On Sun, Jan 31, 2021, at 00:49, Brennan Ashton wrote: > On Sat, Jan 30, 2021 at 6:11 PM Matias N. <mat...@imap.cc> wrote: > > > > > > > This is actually fairly in line with how the Musl libc implements this (at > > > least from a quick look). There are a few important details in there, but > > > it looks quite clean. > > > > > > http://git.musl-libc.org/cgit/musl/tree/src/time/timer_create.c > > > > > > While Musl is usually not as fast as glibc, I find the implementations > > > usually more straight forward and smaller code size. > > > > > > > > > > > > > > From what I see glibc does a similar thing: has one thread that expects a > > signal (and waits for it with sigwait) and > > spawns a new thread to run the user-supplied callback. I think that using a > > single thread to run the callback should be enough (although it could > > easily be made an option to spawn a new thread each time). In this scenario > > SIGEV_THREAD_ID ammounts to simply skipping the thread creation and letting > > the user specify which thread so send the signal to. > > > > What I'm unsure about is if using a signal is really necessary. It seems > > that using a semaphore/condition variable would be simpler and maybe faster. > > > > I think I must not be understanding what you are asking here. Are you > talking about somehow replacing the sigwaiitinfo with > sem_wait/sem_timedwait? I'm not sure how that would actually be faster > or simpler, with sem_wait you will be interrupted by any signal and > then will have to figure out why and possibly wait again with a race > condition (timer could have expired). But it is very possible I am > just not understanding how you would be using the semaphore. > > --Brennan >
