From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4933FE5A.5060501@domain.hid> Date: Mon, 01 Dec 2008 16:10:18 +0100 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <493306F5.2080605@domain.hid> <49330CD3.4090700@domain.hid> <4933BAE2.3000502@domain.hid> <4933F1A4.8060209@domain.hid> <4933F18F.7080103@domain.hid> In-Reply-To: <4933F18F.7080103@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] pthread cancelation and scheduling magics List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wolfgang Grandegger Cc: xenomai-help Gilles Chanteperdrix wrote: >>> Now, the question is, do you realistically plan to write an application >>> which makes no syscall in its real-time loop? >> Unlikely, but it may happen in case of programming errors. Anyhow, the >> pthreads will run legacy code and it would be a pain to add >> pthread_testcancel where necessary. But maybe there is a more elegant >> and simple solution to do a defined exit/abort. > > In case of programming error, enable the xenomai watchdog, it will > forcibly kill the problematic thread. To give you a more complete answer: most blocking functions are cancellation points in the PTHREAD_CANCEL_DEFERRED case, so, you probably do not need to add pthread_testcancel at all. The only exception is pthread_mutex_lock: this way, cancellation happens for well defined mutex states, and you may install cleanup handlers with pthread_cleanup_push/pthread_cleanup_pop if ever a thread may be destroyed while holding a mutex. With PTHREAD_CANCEL_ASYNCHRONOUS, the situation is not that clean. -- Gilles.