Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> > Jan Kiszka wrote:
> > > Gilles Chanteperdrix wrote:
> > > > IMO, the only advantage of having absolute timers is to be able to
> > apply
> > > > the posix scheme. So, if I followed correctly your discussion, what we
> > > > need is:
> > > > - an XNTBISOL flag with a service xntbase_isol which set this flag and
> > > > unshare the target timebase if it is shared (IOW, if aperiodic)
> > > > - the service xntbase_adjust_time to walk all the absolute timers of
> > the
> > > > non isolated timebases and adjust their expiry date or play their
> > > > handler the posix way.
> > >
> > > Two questions came up here regarding item #2:
> > >
> > > - Shouldn't we also adjust the non-monotonic timers of an isolated base
> > > if it asks for wallclock tuning? I think so.
> > >
> > > - We don't have a service to walk the list of all pending timers, do
> > > we? As that touches all of our timer queue variants and I'm not
> > > familiar with their details (except for plain lists...), I would
> > > welcome any support on this.
> > I am afraid for other things than lists, we will have to define an
> > xntimerq_iterator which holds a little bit more information than just a
> > pointer to a holder.
> So we would have to increase the size of each xntimer_t object? Argh.
> Sounds a bit like it's worth to have a closer look at some "two timer
> lists, one with adjustable offset"-approach...
No, I was thinking about defining a new type xntimerq_iterator, whose
sole purpose would be to hold the state of an iteration. In fact, we
only need this in the hashed case, binary heap holders already contain
Xenomai-core mailing list