[Xenomai-help] pthread_setname_np

[Xenomai-help] pthread_setname_np

[Daniel Schnell]

[-- Attachment #1: Type: text/plain, Size: 391 bytes --]

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 ?
 
 
Best regards,
 
Daniel Schnell.

[-- Attachment #2: Type: text/html, Size: 1475 bytes --]

Re: [Xenomai-help] pthread_setname_np

[Gilles Chanteperdrix]

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

RE: [Xenomai-help] pthread_setname_np

[Daniel Schnell]

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 ?

Best regards,

Daniel Schnell.

Re: [Xenomai-help] pthread_setname_np

[Gilles Chanteperdrix]

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

RE: [Xenomai-help] pthread_setname_np

[Daniel Schnell]

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.

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.

Re: [Xenomai-help] pthread_setname_np

[Gilles Chanteperdrix]

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

RE: [Xenomai-help] pthread_setname_np

[Daniel Schnell]

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.

>> 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() ??


Best regards,

Daniel Schnell.

Re: [Xenomai-help] pthread_setname_np

[Gilles Chanteperdrix]

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

RE: [Xenomai-help] [PATCH] pthread_setname_np

[Daniel Schnell]

[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

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.
  *
  * This service set to @a name, the name of @a thread. This name is
used for
  * displaying information in /proc/xenomai/sched.

[-- Attachment #2: patch-docu.txt --]
[-- Type: text/plain, Size: 419 bytes --]

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.
  *
  * This service set to @a name, the name of @a thread. This name is used for
  * displaying information in /proc/xenomai/sched.

RE: [Xenomai-help] [PATCH] pthread_setname_np

[Philippe Gerum]

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.

RE: [Xenomai-help] pthread_setname_np

[Daniel Schnell]

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 ?

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.

Re: [Xenomai-help] pthread_setname_np

[Gilles Chanteperdrix]

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