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 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 > >
