On Sat, Jan 30, 2021 at 7:00 AM Matias N. <mat...@imap.cc> 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 api just a simple wrapper of ioctl.
> 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. > Yes, you have to poll timerfd to know when the timer expires. Basically, there are two programming style: 1. The push mode: library/kernel calls your callback once something happens. 2. The pull mode: your thread block in poll/select or read/write call and wake up when something happens. > Best, > Matias > > On Sat, Jan 30, 2021, at 09:41, Xiang Xiao wrote: > > timerfd is a very nice feature, but is it better to call wd_* api than > timer_ api? > > > > > -----Original Message----- > > > From: Matias N. <mat...@imap.cc> > > > Sent: Saturday, January 30, 2021 10:01 AM > > > To: dev@nuttx.apache.org > > > Subject: 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 timer_* functionality. I was wondering if anyone > already did this work outside of mainline or had any > > thoughts about > > > what to consider when doing so. > > > > > > Best, > > > Matias > > > > >
