You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by "Matias N." <ma...@imap.cc> on 2021/01/12 23:13:24 UTC
condition variables and signals
Hi,
I'm having an issue when waiting on a pthread condition variable from the main thread and then a signal handler runs, which should cancel the wait since I have cancellation points enabled, however this did not happen. While debugging I see the main thread blocked when standing inside the signal handler. Here's the call graph at that point:
If I continue execution, the main thread never runs. I'm wondering if that call to nxsem_wait_uninterruptible is correct since it would seem that is exactly why this is not being canceled.
Note that I was initially signaling the condition variable from within the signal handler but this did not work either. However, looking at pthread documentation this is supposedly not supported: https://linux.die.net/man/3/pthread_cond_signal
(I'm not sure if that really applies to NuttX though).
Also, I'm mixing signals with threads because I'm using POSIX timers which require signals to be handled, so I'm stuck with this. I think supporting timerfd would be really useful (as I could then have a thread that waits on the fd of the timer).
Best,
Matias
Re: condition variables and signals
Posted by Gregory Nutt <sp...@gmail.com>.
> The wait I'm referring to is the one on the semaphore underlying to the condition variable (pthread_sem_take on cond->sem). This ends up as a call to nxsem_wait_uninterruptible which loops on the wait to ignore EINTR errors. So I understand that a signal would not interrupt the wait (and thus, the call to pthread_cond_wait).
When the thread is canceled, nxsem_wait() will return ECANCELED. In that
case, nxsem_wait_interruptible() will return the error.
If you continue to loop, then cancellation is not ocurring (i.e., EINTR
is received not ECANCELED). This would be the case if, for example, you
attached a signal handler to the signal used for cancellation
Re: condition variables and signals
Posted by "Matias N." <ma...@imap.cc>.
The wait I'm referring to is the one on the semaphore underlying to the condition variable (pthread_sem_take on cond->sem). This ends up as a call to nxsem_wait_uninterruptible which loops on the wait to ignore EINTR errors. So I understand that a signal would not interrupt the wait (and thus, the call to pthread_cond_wait).
On Tue, Jan 12, 2021, at 20:34, Gregory Nutt wrote:
>
> > I'm having an issue when waiting on a pthread condition variable from
> > the main thread and then a signal handler runs, which should cancel
> > the wait since I have cancellation points enabled, however this did
> > not happen. While debugging I see the main thread blocked when
> > standing inside the signal handler. Here's the call graph at that point:
>
> There are two semaphores associated with a condition variable wait: a)
> One for the conditional variable and b) one for a mutex that protects
> the condition variable. When you wait for a condition, the mutex (b) is
> unlocked and the logic waits on (a). After (a) wakes up, then mutex (b)
> is re-relocked. So there can be two waits.
>
> What is not clear from the call graph is if the sem_wait() is the first
> for the condition variable or the second for the mutex.
> nxsem_wait_interruptible() is fine for for the first, but not for the
> second if ECANCELED was returned.
>
>
>
Re: condition variables and signals
Posted by Gregory Nutt <sp...@gmail.com>.
> I'm having an issue when waiting on a pthread condition variable from
> the main thread and then a signal handler runs, which should cancel
> the wait since I have cancellation points enabled, however this did
> not happen. While debugging I see the main thread blocked when
> standing inside the signal handler. Here's the call graph at that point:
There are two semaphores associated with a condition variable wait: a)
One for the conditional variable and b) one for a mutex that protects
the condition variable. When you wait for a condition, the mutex (b) is
unlocked and the logic waits on (a). After (a) wakes up, then mutex (b)
is re-relocked. So there can be two waits.
What is not clear from the call graph is if the sem_wait() is the first
for the condition variable or the second for the mutex.
nxsem_wait_interruptible() is fine for for the first, but not for the
second if ECANCELED was returned.
Re: condition variables and signals
Posted by "Matias N." <ma...@imap.cc>.
Thanks Greg for the insight into the problem. The fact that the signal handler
runs in the same thread was not something I thought. Also I think it confirms using
SIGEV_THREAD for this is the safe approach in this scenario.
Best,
Matias
On Wed, Jan 13, 2021, at 19:06, Gregory Nutt wrote:
>
> > I am thinking that there must be some race condition: When the
> > condition variable is created the cond->sem value will be set to
> > zero. While waiting for cond->sem, it will be set to -1. If you see
> > cond->sem equal to zero, my guess would be that the signal was
> > received and cond->sem was incremented asychronously by the signal
> > delivery logic. But that is only a guess.
> >
> I know what is going on. There is no race condition. It is normal
> behavior for a signal handler:
>
> * The signal handler runs on the same thread that receives the signal
> * In order for the signal handler to run, the thread must be running.
> If the thread is blocked, then it must be unblocked so that the
> signal handler can run (that is why EINTR is returned under POSIX...
> To indicate only that the thread had to be unblocked and awakened to
> process a signal).
> * If the thread is blocked waiting on a semaphore, then the semaphore
> count must be incremented in order to unblock the thread.
> * This must happen BEFORE the signal handler runs.
>
> So there is no race condition, instead there is a simple ordering issue
> The sequence above should be modified like:
>
> * When the condition variable is created the cond->sem value will be
> set to zero.
> * While waiting for cond->sem, the value will be decremented to -1
> * When a signal is received, the thread will be awakened be
> incremented back to zero.
> * THEN the thread will run and signal handler will be invoked with the
> cond->sem value ALWAYS equal to zero.
>
> So it is perfectly normal behavior that the cond->sem count is zero in
> this case. It just indicates that the thread is running. So, no, I was
> wrong. It is not possible to use pthread_cond_signal() form a thread to
> wake itself up BECAUSE it already had to be awakened in order for the
> signal handler to run.
>
> When the signal handler returns, pthread_cond_wait() will run inside of
> nxsem_wait_interruptible() and it will correctly ignore the EINTR error
> and call nxsem_wait() again.
>
>
>
>
Re: condition variables and signals
Posted by Gregory Nutt <sp...@gmail.com>.
> I am thinking that there must be some race condition: When the
> condition variable is created the cond->sem value will be set to
> zero. While waiting for cond->sem, it will be set to -1. If you see
> cond->sem equal to zero, my guess would be that the signal was
> received and cond->sem was incremented asychronously by the signal
> delivery logic. But that is only a guess.
>
I know what is going on. There is no race condition. It is normal
behavior for a signal handler:
* The signal handler runs on the same thread that receives the signal
* In order for the signal handler to run, the thread must be running.
If the thread is blocked, then it must be unblocked so that the
signal handler can run (that is why EINTR is returned under POSIX...
To indicate only that the thread had to be unblocked and awakened to
process a signal).
* If the thread is blocked waiting on a semaphore, then the semaphore
count must be incremented in order to unblock the thread.
* This must happen BEFORE the signal handler runs.
So there is no race condition, instead there is a simple ordering issue
The sequence above should be modified like:
* When the condition variable is created the cond->sem value will be
set to zero.
* While waiting for cond->sem, the value will be decremented to -1
* When a signal is received, the thread will be awakened be
incremented back to zero.
* THEN the thread will run and signal handler will be invoked with the
cond->sem value ALWAYS equal to zero.
So it is perfectly normal behavior that the cond->sem count is zero in
this case. It just indicates that the thread is running. So, no, I was
wrong. It is not possible to use pthread_cond_signal() form a thread to
wake itself up BECAUSE it already had to be awakened in order for the
signal handler to run.
When the signal handler returns, pthread_cond_wait() will run inside of
nxsem_wait_interruptible() and it will correctly ignore the EINTR error
and call nxsem_wait() again.
Re: condition variables and signals
Posted by "Matias N." <ma...@imap.cc>.
Thanks. I'm using FLAT mode so no problem.
Best,
Matias
On Wed, Jan 13, 2021, at 11:40, Gregory Nutt wrote:
> Just beware of https://github.com/apache/incubator-nuttx/issues/1352
>
> On 1/13/2021 8:09 AM, Matias N. wrote:
>> Hi,
>> thanks for your responses. Yes, upon more reading I realized mixing signals with pthread mutexes was not safe. I guess
>> I was getting a race condition inside the mutex locking.
>>
>> As a workaround, I resorted to using SIGEV_THREAD notification for POSIX timers. This appears to work and I guess it
>> should be safe. Eventually I will look into implementing timerfd, if anyone else hasn't done so yet.
>>
>> Best,
>> Matias
>>
>> On Wed, Jan 13, 2021, at 05:52, Juha Niskanen (Haltian) wrote:
>>>> BTW, looking at the spec for pthread_cond_wait, there's actually no mention about a limitation regarding using pthread_cond_signal invoked from within a signal handler to unblock a pthread_cond_wait.
>>> The restriction is elsewhere. pthread_cond_signal() is not in the list of async-signal-safe functions at
>>>
>>> https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04
>>>
>>> Therefore, portable programs may not call it from a signal handler and except it to work. Asynchronous signal handler can get called between any two instructions so safe synchronization with condition variables might be hard to implement. Use semaphores and sem_post() instead.
>>>
>>> -Juha
>>>
>>>
>>>
>>> *From:* Gregory Nutt <sp...@gmail.com>
>>> *Sent:* Wednesday, January 13, 2021 4:24 AM
>>> *To:* dev@nuttx.apache.org <de...@nuttx.apache.org>
>>> *Subject:* Re: condition variables and signals
>>>
>>>
>>>> BTW, looking at the spec for pthread_cond_wait, there's actually no mention about a limitation regarding using pthread_cond_signal invoked from within a signal handler to unblock a pthread_cond_wait. However, this does not work
>>>> either for me. If you follow the signal operation, I can see that when it reaches the nxsem_get_value() on the cond->sem, the semaphore value is zero and the sem_give is not done.
>>>>
>>>>
>>>> Should this work?
>>> Yes, calling pthread_cond_signal() should work, however, no signal should be delivered. The word "signal" is overloaded: Here the condition is signaled but no signal should be sent so I am not quite sure what I am looking at. Apparently some other logic is signaling the task group asynchronously?
>>> I am thinking that there must be some race condition: When the condition variable is created the cond->sem value will be set to zero. While waiting for cond->sem, it will be set to -1. If you see cond->sem equal to zero, my guess would be that the signal was received and cond->sem was incremented asychronously by the signal delivery logic. But that is only a guess.
>>> It would be good to check the behavior without the signal interfering.
>>>
>>>
>>>
>>>
>>> *Attachments:*
>>> * image.png
>>
>
>
> *Attachments:*
> * image.png
Re: condition variables and signals
Posted by Gregory Nutt <sp...@gmail.com>.
Just beware of https://github.com/apache/incubator-nuttx/issues/1352
On 1/13/2021 8:09 AM, Matias N. wrote:
> Hi,
> thanks for your responses. Yes, upon more reading I realized mixing
> signals with pthread mutexes was not safe. I guess
> I was getting a race condition inside the mutex locking.
>
> As a workaround, I resorted to using SIGEV_THREAD notification for
> POSIX timers. This appears to work and I guess it
> should be safe. Eventually I will look into implementing timerfd, if
> anyone else hasn't done so yet.
>
> Best,
> Matias
>
> On Wed, Jan 13, 2021, at 05:52, Juha Niskanen (Haltian) wrote:
>>
>> BTW, looking at the spec for pthread_cond_wait, there's actually
>> no mention about a limitation regarding using pthread_cond_signal
>> invoked from within a signal handler to unblock a pthread_cond_wait.
>>
>> The restriction is elsewhere. pthread_cond_signal() is not in the
>> list of async-signal-safe functions at
>>
>> https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04
>> <https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04>
>>
>> Therefore, portable programs may not call it from a signal handler
>> and except it to work. Asynchronous signal handler can get called
>> between any two instructions so safe synchronization with condition
>> variables might be hard to implement. Use semaphores and sem_post()
>> instead.
>>
>> -Juha
>>
>>
>> ------------------------------------------------------------------------
>>
>> *From:* Gregory Nutt <sp...@gmail.com>
>> *Sent:* Wednesday, January 13, 2021 4:24 AM
>> *To:* dev@nuttx.apache.org <de...@nuttx.apache.org>
>> *Subject:* Re: condition variables and signals
>>
>>
>>> BTW, looking at the spec for pthread_cond_wait, there's actually no
>>> mention about a limitation regarding using pthread_cond_signal
>>> invoked from within a signal handler to unblock a pthread_cond_wait.
>>> However, this does not work
>>> either for me. If you follow the signal operation, I can see that
>>> when it reaches the nxsem_get_value() on the cond->sem, the
>>> semaphore value is zero and the sem_give is not done.
>>>
>>>
>>> Should this work?
>>
>> Yes, calling pthread_cond_signal() should work, however, no signal
>> should be delivered. The word "signal" is overloaded: Here the
>> condition is signaled but no signal should be sent so I am not quite
>> sure what I am looking at. Apparently some other logic is signaling
>> the task group asynchronously?
>>
>> I am thinking that there must be some race condition: When the
>> condition variable is created the cond->sem value will be set to
>> zero. While waiting for cond->sem, it will be set to -1. If you see
>> cond->sem equal to zero, my guess would be that the signal was
>> received and cond->sem was incremented asychronously by the signal
>> delivery logic. But that is only a guess.
>>
>> It would be good to check the behavior without the signal interfering.
>>
>>
>>
>>
>>
>> *Attachments:*
>>
>> * image.png
>>
>
Re: condition variables and signals
Posted by "Matias N." <ma...@imap.cc>.
Hi,
thanks for your responses. Yes, upon more reading I realized mixing signals with pthread mutexes was not safe. I guess
I was getting a race condition inside the mutex locking.
As a workaround, I resorted to using SIGEV_THREAD notification for POSIX timers. This appears to work and I guess it
should be safe. Eventually I will look into implementing timerfd, if anyone else hasn't done so yet.
Best,
Matias
On Wed, Jan 13, 2021, at 05:52, Juha Niskanen (Haltian) wrote:
>> BTW, looking at the spec for pthread_cond_wait, there's actually no mention about a limitation regarding using pthread_cond_signal invoked from within a signal handler to unblock a pthread_cond_wait.
> The restriction is elsewhere. pthread_cond_signal() is not in the list of async-signal-safe functions at
>
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04
>
> Therefore, portable programs may not call it from a signal handler and except it to work. Asynchronous signal handler can get called between any two instructions so safe synchronization with condition variables might be hard to implement. Use semaphores and sem_post() instead.
>
> -Juha
>
>
>
> *From:* Gregory Nutt <sp...@gmail.com>
> *Sent:* Wednesday, January 13, 2021 4:24 AM
> *To:* dev@nuttx.apache.org <de...@nuttx.apache.org>
> *Subject:* Re: condition variables and signals
>
>
>> BTW, looking at the spec for pthread_cond_wait, there's actually no mention about a limitation regarding using pthread_cond_signal invoked from within a signal handler to unblock a pthread_cond_wait. However, this does not work
>> either for me. If you follow the signal operation, I can see that when it reaches the nxsem_get_value() on the cond->sem, the semaphore value is zero and the sem_give is not done.
>>
>>
>> Should this work?
> Yes, calling pthread_cond_signal() should work, however, no signal should be delivered. The word "signal" is overloaded: Here the condition is signaled but no signal should be sent so I am not quite sure what I am looking at. Apparently some other logic is signaling the task group asynchronously?
> I am thinking that there must be some race condition: When the condition variable is created the cond->sem value will be set to zero. While waiting for cond->sem, it will be set to -1. If you see cond->sem equal to zero, my guess would be that the signal was received and cond->sem was incremented asychronously by the signal delivery logic. But that is only a guess.
> It would be good to check the behavior without the signal interfering.
>
>
>
>
> *Attachments:*
> * image.png
Re: condition variables and signals
Posted by "Juha Niskanen (Haltian)" <ju...@haltian.com>.
BTW, looking at the spec for pthread_cond_wait, there's actually no mention about a limitation regarding using pthread_cond_signal invoked from within a signal handler to unblock a pthread_cond_wait.
The restriction is elsewhere. pthread_cond_signal() is not in the list of async-signal-safe functions at
https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04
Therefore, portable programs may not call it from a signal handler and except it to work. Asynchronous signal handler can get called between any two instructions so safe synchronization with condition variables might be hard to implement. Use semaphores and sem_post() instead.
-Juha
________________________________
From: Gregory Nutt <sp...@gmail.com>
Sent: Wednesday, January 13, 2021 4:24 AM
To: dev@nuttx.apache.org <de...@nuttx.apache.org>
Subject: Re: condition variables and signals
BTW, looking at the spec for pthread_cond_wait, there's actually no mention about a limitation regarding using pthread_cond_signal invoked from within a signal handler to unblock a pthread_cond_wait. However, this does not work
either for me. If you follow the signal operation, I can see that when it reaches the nxsem_get_value() on the cond->sem, the semaphore value is zero and the sem_give is not done.
[cid:part1.02F16F75.CA50FB6D@gmail.com]
Should this work?
Yes, calling pthread_cond_signal() should work, however, no signal should be delivered. The word "signal" is overloaded: Here the condition is signaled but no signal should be sent so I am not quite sure what I am looking at. Apparently some other logic is signaling the task group asynchronously?
I am thinking that there must be some race condition: When the condition variable is created the cond->sem value will be set to zero. While waiting for cond->sem, it will be set to -1. If you see cond->sem equal to zero, my guess would be that the signal was received and cond->sem was incremented asychronously by the signal delivery logic. But that is only a guess.
It would be good to check the behavior without the signal interfering.
Re: condition variables and signals
Posted by Gregory Nutt <sp...@gmail.com>.
> BTW, looking at the spec for pthread_cond_wait, there's actually no
> mention about a limitation regarding using pthread_cond_signal invoked
> from within a signal handler to unblock a pthread_cond_wait. However,
> this does not work
> either for me. If you follow the signal operation, I can see that when
> it reaches the nxsem_get_value() on the cond->sem, the semaphore value
> is zero and the sem_give is not done.
>
> Should this work?
>
Yes, calling pthread_cond_signal() should work, however, no signal
should be delivered. The word "signal" is overloaded: Here the
condition is signaled but no signal should be sent so I am not quite
sure what I am looking at. Apparently some other logic is signaling the
task group asynchronously?
I am thinking that there must be some race condition: When the
condition variable is created the cond->sem value will be set to zero.
While waiting for cond->sem, it will be set to -1. If you see cond->sem
equal to zero, my guess would be that the signal was received and
cond->sem was incremented asychronously by the signal delivery logic.
But that is only a guess.
It would be good to check the behavior without the signal interfering.
Re: condition variables and signals
Posted by "Matias N." <ma...@imap.cc>.
> Note that I was initially signaling the condition variable from within the signal handler but this did not work either. However, looking at pthread documentation this is supposedly not supported: https://linux.die.net/man/3/pthread_cond_signal
> (I'm not sure if that really applies to NuttX though).
>
BTW, looking at the spec for pthread_cond_wait, there's actually no mention about a limitation regarding using pthread_cond_signal invoked from within a signal handler to unblock a pthread_cond_wait. However, this does not work
either for me. If you follow the signal operation, I can see that when it reaches the nxsem_get_value() on the cond->sem, the semaphore value is zero and the sem_give is not done.
Should this work?
Best,
Matia
Re: condition variables and signals
Posted by "Matias N." <ma...@imap.cc>.
Ahh ok. Thanks for that, should've looked further into the spec. I assumed from other documentation I read that it could work.
So, now I'm a bit stuck on mixing the signal-based POSIX timers with mutexes. I will see about other synchronization mechanism.
Best,
Matias
On Tue, Jan 12, 2021, at 21:19, Gregory Nutt wrote:
>
> > pthread_cond_wait() is not supposed to return if a signal is received:
> > https://pubs.opengroup.org/onlinepubs/009696699/functions/pthread_cond_wait.html
> >
> > EINTR is not one of the valid return values from pthread_cond_wait().
>
> This is the specific POSIX requirement that must be followed: "If a
> signal is delivered to a thread waiting for a condition variable, upon
> return from the signal handler the thread resumes waiting for the
> condition variable as if it was not interrupted, or it shall return zero
> due to spurious wakeup."
>
> "Spurious wakeups" are not handled.
>
>
Re: condition variables and signals
Posted by Gregory Nutt <sp...@gmail.com>.
> pthread_cond_wait() is not supposed to return if a signal is received:
> https://pubs.opengroup.org/onlinepubs/009696699/functions/pthread_cond_wait.html
>
> EINTR is not one of the valid return values from pthread_cond_wait().
This is the specific POSIX requirement that must be followed: "If a
signal is delivered to a thread waiting for a condition variable, upon
return from the signal handler the thread resumes waiting for the
condition variable as if it was not interrupted, or it shall return zero
due to spurious wakeup."
"Spurious wakeups" are not handled.
Re: condition variables and signals
Posted by Gregory Nutt <sp...@gmail.com>.
> I'm not expecting the task to be killed, but the pthread_cond_wait to return when the process receives a signal (which I'm handling in a signal handler).
>
> What I need is to exit the pthread_cond_wait upon reception of the signal. As I mentioned, doing pthread_cond_signal from the handler did not work (and seems not to be safe) and now I was trying to enable cancellation points so that the signal itself cancels pthread_cond_wait.
pthread_cond_wait() is not supposed to return if a signal is received:
https://pubs.opengroup.org/onlinepubs/009696699/functions/pthread_cond_wait.html
EINTR is not one of the valid return values from pthread_cond_wait().
Re: condition variables and signals
Posted by "Matias N." <ma...@imap.cc>.
I'm not expecting the task to be killed, but the pthread_cond_wait to return when the process receives a signal (which I'm handling in a signal handler).
What I need is to exit the pthread_cond_wait upon reception of the signal. As I mentioned, doing pthread_cond_signal from the handler did not work (and seems not to be safe) and now I was trying to enable cancellation points so that the signal itself cancels pthread_cond_wait.
Best,
Matias
On Tue, Jan 12, 2021, at 21:00, Gregory Nutt wrote:
>
>
> > I'm having an issue when waiting on a pthread condition variable from
> > the main thread and then a signal handler runs, which should cancel
> > the wait since I have cancellation points enabled, however this did
> > not happen.
>
> I don't understand this either. A signal will not, in general, cause a
> task to be killed. The DEFAULT behavior of some signals (if enabled)
> will kill the task.
>
> However, if you have connected a signal handler via sigaction(), then
> you have also disabled the default behavior and the task will not be killed.
>
>
Re: condition variables and signals
Posted by Gregory Nutt <sp...@gmail.com>.
> I'm having an issue when waiting on a pthread condition variable from
> the main thread and then a signal handler runs, which should cancel
> the wait since I have cancellation points enabled, however this did
> not happen.
I don't understand this either. A signal will not, in general, cause a
task to be killed. The DEFAULT behavior of some signals (if enabled)
will kill the task.
However, if you have connected a signal handler via sigaction(), then
you have also disabled the default behavior and the task will not be killed.
Re: condition variables and signals
Posted by Gregory Nutt <sp...@gmail.com>.
> As a quick test, I made pthread_cond_wait call to pthread_sem_take
> with the last argument to true (which then use the interruptible
> version) and it now cancels the wait. So it would seem that this is a
> bug right?
>
nxsem_wait_uninterruptible() should have no effect on thread
cancellation (i.e., it should still return ECANCELED). This only
effects signal interrupts (EINTR).
So at this superficial level of analysis, nxsem_wait_uninterruptible()
should be correct. There is something else going on.
Re: condition variables and signals
Posted by "Matias N." <ma...@imap.cc>.
As a quick test, I made pthread_cond_wait call to pthread_sem_take with the last argument to true (which then use the interruptible version) and it now cancels the wait. So it would seem that this is a bug right?
Best,
Matias
On Tue, Jan 12, 2021, at 20:13, Matias N. wrote:
> Hi,
> I'm having an issue when waiting on a pthread condition variable from the main thread and then a signal handler runs, which should cancel the wait since I have cancellation points enabled, however this did not happen. While debugging I see the main thread blocked when standing inside the signal handler. Here's the call graph at that point:
>
> If I continue execution, the main thread never runs. I'm wondering if that call to nxsem_wait_uninterruptible is correct since it would seem that is exactly why this is not being canceled.
>
> Note that I was initially signaling the condition variable from within the signal handler but this did not work either. However, looking at pthread documentation this is supposedly not supported: https://linux.die.net/man/3/pthread_cond_signal
> (I'm not sure if that really applies to NuttX though).
>
> Also, I'm mixing signals with threads because I'm using POSIX timers which require signals to be handled, so I'm stuck with this. I think supporting timerfd would be really useful (as I could then have a thread that waits on the fd of the timer).
>
> Best,
> Matias
>
> *Attachments:*
> * image.png