On Sat, Jan 30, 2021, at 12:26, Xiang Xiao wrote:
> On Sat, Jan 30, 2021 at 7:00 AM Matias N. wrote:
>
> > But that isn't a userspace API, is it? It runs the handler in interrupt
> > context.
> >
> >
> The core logic for timerfd is part of the kernel(
On Sat, Jan 30, 2021 at 7:00 AM Matias N. wrote:
> But that isn't a userspace API, is it? It runs the handler in interrupt
> context.
>
>
The core logic for timerfd is part of the kernel(actually, timerfd/eventfd
implements file_operation like a normal driver). libc timerfd
But that isn't a userspace API, is it? It runs the handler in interrupt context.
I also realize now that timerfd has a limitation: you will not know about the
timer expiration
while not yet doing poll, so it looses a bit on the real-time aspect.
Best,
Matias
On Sat, Jan 30, 2021, at
timerfd is a very nice feature, but is it better to call wd_* api than timer_
api?
> -Original Message-
> From: Matias N.
> Sent: Saturday, January 30, 2021 10:01 AM
> To: dev@nuttx.apache.org
> Subject: timerfd
>
> Hi,
>
> I would like to implement timerfd
Hi,
I would like to implement timerfd interface to overcome some of the issues
around handling signals and threads and the limitation of SIGEV_THREAD we
discussed. I see eventfd is supported and looking at the implementation I think
it can be done relatively simple using most of the existing
