From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [Xenomai-core] Timer optimisations, continued From: Philippe Gerum In-Reply-To: <44C8C5B0.9080000@domain.hid> References: <448E98A3.6080707@domain.hid> <448E9E8B.70809@domain.hid> <448EA7F7.5000802@domain.hid> <448EB038.8070802@domain.hid> <448EE593.7010809@domain.hid> <448EF022.1040901@domain.hid> <17550.61982.685449.470866@domain.hid> <44C6626A.6000304@domain.hid> <1153990428.5251.46.camel@domain.hid> <17608.46241.732781.448429@domain.hid> <1154006347.4984.2.camel@domain.hid> <44C8C5B0.9080000@domain.hid> Content-Type: text/plain Date: Thu, 27 Jul 2006 16:10:47 +0200 Message-Id: <1154009448.4984.16.camel@domain.hid> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: rpm@xenomai.org List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: xenomai-core 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.