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
enough information.

-- 


                                            Gilles Chanteperdrix.

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to