The prototype of the SIGEV_THREAD callback is |void(*)(union
sigval).|||The waiting thread would also need the union sigval data
which accompanies the signal. If you are not using a signal, then you
have to come up with some other mechanism to pass the union sigval data.
On 1/31/2021 9:34 AM, Matias N. wrote:
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
