From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C708A9.0D6ED20D" Date: Wed, 15 Nov 2006 11:27:36 -0000 Message-ID: From: "Daniel Schnell" Subject: [Xenomai-help] pthread_setname_np List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: xenomai@xenomai.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C708A9.0D6ED20D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 this function does not change the name inside /proc/xenomai/stat or sched for user space Posix threads. As I understand the other function pthread_attr_setname_np() is only valid (and available) for Kernel level threads. =20 Is there any way that works correctly to name a thread to something different than simply the executable name ? =20 =20 Best regards, =20 Daniel Schnell. ------_=_NextPart_001_01C708A9.0D6ED20D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

this = function does=20 not change the name inside /proc/xenomai/stat or sched for user space = Posix=20 threads. As I understand the other function pthread_attr_setname_np() is = only=20 valid (and available) for Kernel level threads.

Is = there any way=20 that works correctly to name a thread to something different = than simply=20 the executable name ?

Best=20 regards,

Daniel = Schnell.

------_=_NextPart_001_01C708A9.0D6ED20D-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <455B11AC.7000300@domain.hid> Date: Wed, 15 Nov 2006 14:10:04 +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: > Hi, > > this function does not change the name inside /proc/xenomai/stat or > sched for user space Posix threads. As I understand the other function > pthread_attr_setname_np() is only valid (and available) for Kernel level > threads. > > Is there any way that works correctly to name a thread to something > different than simply the executable name ? I tested pthread_set_name_np with the "switchtest" program on x86 and ARM, and it works. Could you run switchtest on your platform and see if the information in /proc/xenomai/sched is correct ? -- Gilles Chanteperdrix From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Xenomai-help] pthread_setname_np Date: Wed, 15 Nov 2006 13:31:49 -0000 Message-ID: In-Reply-To: <455B11AC.7000300@domain.hid> From: "Daniel Schnell" List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: xenomai@xenomai.org Hi, Gilles Chanteperdrix wrote: > I tested pthread_set_name_np with the "switchtest" program on x86 and > ARM, and it works. Could you run switchtest on your platform and see > if the information in /proc/xenomai/sched is correct ? =20 The switchtest program works here correctly as well. Looking at the switchtest code I found out that one has to call this function _after_ one has actually created the thread with pthread_create() not like pthread_attr_setXXXX() functions which have to be called before. After changing the order in my code, it worked there as well. Is this behaviour intended ? Best regards, Daniel Schnell. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <455B1966.10609@domain.hid> Date: Wed, 15 Nov 2006 14:43:02 +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: > Hi, > > Gilles Chanteperdrix wrote: > > >>I tested pthread_set_name_np with the "switchtest" program on x86 and >>ARM, and it works. Could you run switchtest on your platform and see >>if the information in /proc/xenomai/sched is correct ? > > > The switchtest program works here correctly as well. Looking at the > switchtest code I found out that one has to call this function _after_ > one has actually created the thread with pthread_create() not like > pthread_attr_setXXXX() functions which have to be called before. After > changing the order in my code, it worked there as well. > > Is this behaviour intended ? pthread_set_name_np requires a pthread_t argument, and returns ESRCH if this argument is invalid. It is supposed to be documented at: http://www.xenomai.org/documentation/trunk/html/api/group__posix__thread.html#g414a759c928f7be7ac105980d8e73431 -- Gilles Chanteperdrix From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Xenomai-help] pthread_setname_np Date: Wed, 15 Nov 2006 14:26:23 -0000 Message-ID: In-Reply-To: <455B1966.10609@domain.hid> From: "Daniel Schnell" List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: xenomai@xenomai.org Gilles Chanteperdrix wrote: >> The switchtest program works here correctly as well. Looking at the >> switchtest code I found out that one has to call this function >> _after_ one has actually created the thread with pthread_create() >> not like pthread_attr_setXXXX() functions which have to be called >> before. After changing the order in my code, it worked there as well. >>=20 >> Is this behaviour intended ? >=20 > pthread_set_name_np requires a pthread_t argument, and returns ESRCH > if this argument is invalid. It is supposed to be documented at: > http://www.xenomai.org/documentation/trunk/html/api/group__posix__thread .html#g414a759c928f7be7ac105980d8e73431 Yes it is documented and one can guess that the function only should be called for a valid thread, i.e. a thread that is already created by reading the part of the documentation which mentions the error code. But as this is a non standard function and normally for Posix threads one expects to specify all attributes before spawning a thread (compare also pthread_attr_setname_np()), maybe one should add a sentence in the documentation, stating that this function is only valid for an already running thread. Btw. Is there a reason why the call to pthread_attr_setname_np() is limited to kernel space ? Best regards, Daniel Schnell. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <455B29BE.3060805@domain.hid> Date: Wed, 15 Nov 2006 15:52:46 +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 switchtest program works here correctly as well. Looking at the >>>switchtest code I found out that one has to call this function >>>_after_ one has actually created the thread with pthread_create() >>>not like pthread_attr_setXXXX() functions which have to be called >>>before. After changing the order in my code, it worked there as well. >>> >>>Is this behaviour intended ? >> >>pthread_set_name_np requires a pthread_t argument, and returns ESRCH >>if this argument is invalid. It is supposed to be documented at: >> > > http://www.xenomai.org/documentation/trunk/html/api/group__posix__thread > .html#g414a759c928f7be7ac105980d8e73431 > > Yes it is documented and one can guess that the function only should be > called for a valid thread, i.e. a thread that is already created by > reading the part of the documentation which mentions the error code. You are being dishonest: the function expects a pthread_t argument, the only way to get a valid pthread_t value is to create a thread or to call pthread_self(). > > But as this is a non standard function and normally for Posix threads > one expects to specify all attributes before spawning a thread (compare > also pthread_attr_setname_np()), maybe one should add a sentence in the > documentation, stating that this function is only valid for an already > running thread. Look again at the POSIX API: functions which set an attribute before spawning the thread are all called pthread_attr_*, pthread_set_name_np is not the only function which allow to change the attribute of a running thread, there is also pthread_detach or pthread_setschedparam. Like these standard functions pthread_set_name_np is prefixed with pthread, and not with pthread_attr. > > Btw. Is there a reason why the call to pthread_attr_setname_np() is > limited to kernel space ? It is impossible to implement pthread_attr_setname_np in user-space. I think I will remove this call, having different APIs in kernel-space and user-space only adds confusion. -- Gilles Chanteperdrix From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Xenomai-help] pthread_setname_np Date: Wed, 15 Nov 2006 15:49:28 -0000 Message-ID: In-Reply-To: <455B29BE.3060805@domain.hid> From: "Daniel Schnell" List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: xenomai@xenomai.org Gilles Chanteperdrix wrote: > You are being dishonest: the function expects a pthread_t argument, > the only way to get a valid pthread_t value is to create a thread or > to call pthread_self(). =20 No only a dumb newbie user of the Posix API with a background of VxWorks. If I want to create a task in VxWorks with e.g. int taskSpawn() I get explecitly back a task id, comparable to a pthread_t for POSIX API. Because it is a simple int (which is in fact not really true, because it is a pointer in the task control block casted into an int), I know as a dumb user that I cannot use it somehow before. With pthreads I did the following: pthread_t thread; pthread_attr_t attr; pthread_attr_init (&attr); pthread_attr_setname_np(&attr, "newname"); (--> pthread_set_name_np(thread, "newname");) pthread_create (&thread, &attr, func, arg); This did not compile, because only valid in kernel space, so I replaced pthread_attr_setname_np() with pthread_set_name_np() and let it run. Of course checking return values could have helped here. I expected that pthread_t is a normal structure and would only be modified with pthread_set_name_np() aka the attribute structure with pthread_attr_setxxx(). I am simply not used to an API that doesn't provide the possibility to spawn a thread already with the correct name and rather forces the user to change the name after the thread is already running ... A collegue of mine stumbled over the exact same thing. A bit more "redundancy" in the documentation would probably have opened our eyes, although it seems according to Google that I am the first mentioning this problem. >> Btw. Is there a reason why the call to pthread_attr_setname_np() is >> limited to kernel space ? >=20 > It is impossible to implement pthread_attr_setname_np in user-space. > I think I will remove this call, having different APIs in > kernel-space and user-space only adds confusion. =20 Just out of curiosity: what are the exact reasons ? I mean: couldn't you principially pass any information to the Xenomai subsystem at the time of a pthread_create() ?? Best regards, Daniel Schnell. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <455B3B6B.1030109@domain.hid> Date: Wed, 15 Nov 2006 17:08:11 +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: > > >>You are being dishonest: the function expects a pthread_t argument, >>the only way to get a valid pthread_t value is to create a thread or >>to call pthread_self(). > > > No only a dumb newbie user of the Posix API with a background of > VxWorks. > If I want to create a task in VxWorks with e.g. int taskSpawn() I get > explecitly back a task id, comparable to a pthread_t for POSIX API. > Because it is a simple int (which is in fact not really true, because it > is a pointer in the task control block casted into an int), I know as a > dumb user that I cannot use it somehow before. > > With pthreads I did the following: > > pthread_t thread; > pthread_attr_t attr; > pthread_attr_init (&attr); > pthread_attr_setname_np(&attr, "newname"); (--> > pthread_set_name_np(thread, "newname");) > pthread_create (&thread, &attr, func, arg); > > > This did not compile, because only valid in kernel space, so I replaced > pthread_attr_setname_np() with pthread_set_name_np() and let it run. Of > course checking return values could have helped here. > > I expected that pthread_t is a normal structure and would only be > modified with pthread_set_name_np() aka the attribute structure with > pthread_attr_setxxx(). I am simply not used to an API that doesn't > provide the possibility to spawn a thread already with the correct name > and rather forces the user to change the name after the thread is > already running ... > A collegue of mine stumbled over the exact same thing. A bit more > "redundancy" in the documentation would probably have opened our eyes, > although it seems according to Google that I am the first mentioning > this problem. If you feel like modifying the documentation, please send a patch. > > >>>Btw. Is there a reason why the call to pthread_attr_setname_np() is >>>limited to kernel space ? >> >>It is impossible to implement pthread_attr_setname_np in user-space. >>I think I will remove this call, having different APIs in >>kernel-space and user-space only adds confusion. > > > Just out of curiosity: what are the exact reasons ? I mean: couldn't you > principially pass any information to the Xenomai subsystem at the time > of a pthread_create() ?? 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. -- Gilles Chanteperdrix From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C708D7.01E03B37" Subject: RE: [Xenomai-help] [PATCH] pthread_setname_np Date: Wed, 15 Nov 2006 16:56:34 -0000 Message-ID: In-Reply-To: <455B3B6B.1030109@domain.hid> From: "Daniel Schnell" List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: xenomai@xenomai.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C708D7.01E03B37 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Gilles Chanteperdrix wrote: > If you feel like modifying the documentation, please send a patch. Here is the patch. Best regards, Daniel Index: ksrc/skins/posix/thread.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- ksrc/skins/posix/thread.c (revision 1834) +++ ksrc/skins/posix/thread.c (working copy) @@ -650,7 +650,7 @@ } /** - * Set a thread name. + * Set the name of a running thread. * * This service set to @a name, the name of @a thread. This name is used for * displaying information in /proc/xenomai/sched. ------_=_NextPart_001_01C708D7.01E03B37 Content-Type: text/plain; name="patch-docu.txt" Content-Transfer-Encoding: base64 Content-Description: patch-docu.txt Content-Disposition: attachment; filename="patch-docu.txt" SW5kZXg6IGtzcmMvc2tpbnMvcG9zaXgvdGhyZWFkLmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0ga3NyYy9za2lu cy9wb3NpeC90aHJlYWQuYyAgIChyZXZpc2lvbiAxODM0KQorKysga3NyYy9za2lucy9wb3NpeC90 aHJlYWQuYyAgICh3b3JraW5nIGNvcHkpCkBAIC02NTAsNyArNjUwLDcgQEAKIH0KCiAvKioKLSAq IFNldCBhIHRocmVhZCBuYW1lLgorICogU2V0IHRoZSBuYW1lIG9mIGEgcnVubmluZyB0aHJlYWQu CiAgKgogICogVGhpcyBzZXJ2aWNlIHNldCB0byBAYSBuYW1lLCB0aGUgbmFtZSBvZiBAYSB0aHJl YWQuIFRoaXMgbmFtZSBpcyB1c2VkIGZvcgogICogZGlzcGxheWluZyBpbmZvcm1hdGlvbiBpbiAv cHJvYy94ZW5vbWFpL3NjaGVkLgo= ------_=_NextPart_001_01C708D7.01E03B37-- From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Xenomai-help] pthread_setname_np Date: Wed, 15 Nov 2006 17:02:31 -0000 Message-ID: In-Reply-To: <455B3B6B.1030109@domain.hid> From: "Daniel Schnell" List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: xenomai@xenomai.org 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. =20 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 ? I find the function pthread_attr_set_name_np() more natural than the other function, because normally one decides upon the name of a thread at startup time, not afterwards. Having both options should be enough for everybody, and is somehow consistent with the VxWorks API that you support as well. Best regards, Daniel Schnell. From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: RE: [Xenomai-help] [PATCH] pthread_setname_np From: Philippe Gerum In-Reply-To: References: Content-Type: text/plain Date: Wed, 15 Nov 2006 18:50:01 +0100 Message-Id: <1163613001.4974.17.camel@domain.hid> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: rpm@xenomai.org 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 On Wed, 2006-11-15 at 16:56 +0000, Daniel Schnell wrote: > Gilles Chanteperdrix wrote: > > > If you feel like modifying the documentation, please send a patch. > > Here is the patch. > > Best regards, > > Daniel > > > > Index: ksrc/skins/posix/thread.c > =================================================================== > --- ksrc/skins/posix/thread.c (revision 1834) > +++ ksrc/skins/posix/thread.c (working copy) > @@ -650,7 +650,7 @@ > } > > /** > - * Set a thread name. > + * Set the name of a running thread. s/running/existing/ which boils down to documenting the fact that you must apply this thread-related request against a valid thread. I'm not sure this is worth a patch, actually. -- Philippe. 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