From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48F350C8.9020102@domain.hid> Date: Mon, 13 Oct 2008 15:44:40 +0200 From: Philippe Gerum MIME-Version: 1.0 References: <48F2118A.7010608@domain.hid> <48F34501.6040802@domain.hid> <48F34673.8060906@domain.hid> In-Reply-To: <48F34673.8060906@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] Using SIGWINCH to trigger priority change. 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: Gilles Chanteperdrix Cc: xenomai-core Gilles Chanteperdrix wrote: > Philippe Gerum wrote: >> (*) Btw, if you happen to export the current thread state via the shared heap to >> userland for the fast mutexes, I guess that we could to use it as well to >> implement a smarter pthread_setschedparam/rt_task_set_priority, doing something >> like: >> >> if (in_secondary_mode(ptid)) >> __real_pthread_setschedparam(...); >> else >> XENOMAI_SKINCALL(...); >> >> When running in secondary mode, we should be able to rely on the automatic >> propagation the nucleus does in do_setsched_event(), if the underlying priority >> scale is POSIX-compatible, which will work for the native skin as well. > > If we export the thread state to user-space there are many things we can > do from user-space, such as disabling preemption for instance. > I'm unsure if this one deserves the burden of dealing with the nesting counter and rescheduling logic from userland. Disabling preemption in apps is something that looks fishy enough to refrain from optimizing the case. -- Philippe.