From mboxrd@z Thu Jan 1 00:00:00 1970 From: Philippe Gerum In-Reply-To: <4E1AE8AD.9060703@domain.hid> References: <4E1AD8DD.3060904@domain.hid> <4E1AE8AD.9060703@domain.hid> Content-Type: text/plain; charset="UTF-8" Date: Mon, 11 Jul 2011 15:25:55 +0200 Message-ID: <1310390755.2154.75.camel@domain.hid> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] Problems with gdb and rt_task_delete List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: Adrien LEMAITRE , xenomai@xenomai.org On Mon, 2011-07-11 at 14:12 +0200, Gilles Chanteperdrix wrote: > On 07/11/2011 01:48 PM, Adrien LEMAITRE wrote: > > 2011/7/11 Gilles Chanteperdrix > > > >> On 07/11/2011 11:50 AM, Adrien LEMAITRE wrote: > >>> Hello, > >>> > >>> I have two problems. Just before explain my problems i would like to > >> clarify > >>> the context. This exercice is for student. In this exercice, they program > >> a > >>> WorkingTask (infini loop) > >> > >> That is the problem, there should not busy inifinite loops. > >> rt_task_sleep(100) asks for 100ns sleep, which is equivalent to not > >> sleeping at all. > >> > >> I seem to remember that I already told you this in answer to your > >> previous post. > >> > > > > yes and thanks you, i have a better understanding now. So ok if i would like > > to make an infini loop i must add a sleep of 5ms, otherwise i have problems. > > That is why i had needed rt_task_suspend(). And the problem with gdb is > > gone. > > > > But i don't see information of this in the wiki, could you show me exactly > > where i can find it? > > > > You can probably sleep for shorter times than 5ms, 100us should be > enough. This is not documented, because it is an unwanted shortcoming, > which we hope to avoid one day, by implementing signals for xenomai, > working even for interrupting an infinite busy loop. > I won't call this a shortcoming, it is rather that you can't expect two kernels to run on the same hardware without sharing the CPU between them somehow, even if unfairly as we do. In the present case, enabling CONFIG_XENO_OPT_WATCHDOG would prevent the total lockup. -- Philippe.