On Thu, 2006-07-27 at 15:54 +0200, Jan Kiszka wrote: > Philippe Gerum wrote: > > On Thu, 2006-07-27 at 14:42 +0200, Gilles Chanteperdrix wrote: > >> Philippe Gerum wrote: > >> > > o A further improvement should be achievable for scenarios 4 and 5 by > >> > > introducing absolute xntimers (more precisely: a flag to > >> > > differentiate between the mode on xntimer_start). I have an > >> outdated > >> > > patch for this in my repos, needs re-basing. > >> > > > >> > > >> > Grmblm... Well, I would have preferred that we don't add that kind of > >> > complexity to the nucleus interface, but I must admit that some > >> > important use cases are definitely better served by absolute timespecs, > >> > so I would surrender to this requirement, provided the implementation is > >> > confined to xnpod_suspend_thread() + xntimer_start(). > >> > >> It would be nice if absolute timeouts were also available when using > >> xnsynch_sleep_on. There are a few use cases in the POSIX skin. > > > > Makes sense, since xnpod_suspend_thread() and xnsynch_sleep_on() are > > tightly integrated interfaces. > > > > Anyone any idea how to extend both function interfaces best to > differentiate absolute/relative timeouts? I guess we need an additional > argument to the functions, don't we?
Yes, I'm afraid we do. The other approach that would basically make the timeout a non-scalar value in order to store the rel/abs qualifier would be just overkill. > > I had the weird idea of using the sign bit of the timeout value for > this. But the potential side effects of halving the absolute time domain > this way scares me. > Same here, this looks like a very fragile solution to a general issue. -- Philippe. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
