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
