From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <455B5489.4070900@domain.hid> Date: Wed, 15 Nov 2006 18:55:21 +0100 From: Gilles Chanteperdrix MIME-Version: 1.0 Subject: Re: [Xenomai-help] pthread_setname_np References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Daniel Schnell Cc: xenomai@xenomai.org Daniel Schnell wrote: > Gilles Chanteperdrix wrote: > > >>The problem is that we would have to store this additional >>information in the pthread_attr_t structure. And in order to allow >>users to include and use the Xenomai API and the native pthread API >>at the same time, Xenomai use the same definition for all the >>pthread_* types as the native pthread API, and we do not know if the >>native API has room for an additional string. > > > Which are the space constraints here ? Do we have a fixed amount of > bytes that maybe inside the pthread_t structure ? Is there a > compatibility issue to older Xenomai versions ? The pthread_attr_t structure is handled by Xenomai as an opaque type. We do not know if there is room for an additional pointer there, and we do not want to know it; even if there was some room in one version of the glibc, we would not have any guarantee that this space exists in later versions. It is a tradeoff: handling pthread_attr_t as an opaque structure is very convenient whereas having to use pthread_set_name_np is a minor inconvenience. -- Gilles Chanteperdrix