Thanks for looking into it Paul!

I can't comment on strace; I've only ever used it to figure out which
files a process was (usually failing to) open silently. As for the
thread naming...

I am using the current orocos release version (2.6), installed via the
autoproj package manager....

Looking at the source I see the same bits of source, i.e. where
setActivity is internally calling setNamedActivity:

bool DeploymentComponent::setActivity(const std::string& comp_name,
double period, int priority,
int scheduler)
{
if ( this->setNamedActivity(comp_name, "Activity", period,
priority, scheduler) ) {...

This is how we are launching our activities at the moment:
$ grep Activity dmhe_testing.ops
setActivity("soemMaster", 0.001, soemPrio, ORO_SCHED_RT)
setActivity("masterTimer", 1.0 / base_hz, masterTimerPrio, ORO_SCHED_RT)
setActivity("mcuHandler", 0.002, sensorPrio, ORO_SCHED_RT)
setActivity("voltageController", 0.01, sensorPrio, ORO_SCHED_RT)
setActivity("encoder", 0.0, sensorPrio, ORO_SCHED_RT)
...
setActivity("lineAngleReporter", 0.0, LowestPriority, ORO_SCHED_RT)
setActivity("mheReporter", 0.0, LowestPriority, ORO_SCHED_RT)

Note that some of the components are periodic, and some are not (since
their period is set to 0.0). However, I do not observe any automatic
naming of any of my component threads:

$ ps -eL | grep depl
4359 4359 pts/0 00:00:00 depl:McuHandler
4359 4360 pts/0 00:00:00 deployer-gnulin
...
4359 4389 pts/0 00:00:05 deployer-gnulin
4359 4390 pts/0 00:00:03 deployer-gnulin
4359 4391 pts/0 00:00:00 deployer-gnulin
4359 4392 pts/0 00:00:00 depl:McuHandler

Only the thread associated with my McuHandler component is showing up,
as I have manually named it in the component's configureHook:

$ grep -C 4 pthread mcuHandler.cpp
#include <pthread.h>
bool McuHandler::configureHook()
{
pthread_setname_np(pthread_self(), "depl:McuHandler");
return true;
}

before I updated to the pthread call, I also tried the prctl method
and it worked too, so it's not a prctl vs. pthread thing.

my kernel at the moment is 3.2.0-30-generic (ubuntu 12.04)
my libc is:
$ aptitude show libc6 | grep Version
Version: 2.15-0ubuntu10

I have not studied the sources well enough to know if it's a bug, or a
feature that just isn't fully implemented yet in orocos 2.6.... anyone
know?

If someone thinks automatic thread naming is working in the latest dev
version, I can try building that with the new catkin meta meta build
system...

On Wed, Oct 30, 2013 at 9:35 PM, Paul Chavent <paul [dot] chavent [..] ...> wrote:
> Hi
>
>
> On 10/30/2013 11:23 AM, Andrew Wagner wrote:
>>
>> Hi Paul!
>>
>> I was just about to post thread naming as a feature request for
>> orocos! I manually played around a bit with adding pthread_setname_np
>> calls to my configure hooks, and trying to find the threads using top,
>> htop, ps, etc...
>>
>> I was planning to write shell scripts that grep around in /proc and
>> /sys/kernel/debug to find the processes I care about, and manage
>> priorities from there. IMHO, setting the priorities in deployer
>> scripts isn't all that great; I think it would be a lot easier to mess
>> around with priorities while your control algorithm is running
>> (assuming you won't break any hardware).
>
>
> I'm not really confident with dynamic scheduling. Otherwise the
> SCHED_DEADLINE is something i will be watching...
>
>
>>
>> Maybe it's even possible to have some semi-generalized performance
>> metrics that are also computed completely outside of your deployment
>> and component definitions...
>>
>> I glanced at your patch description. A couple comments:
>>
>> 1. It sounds like you provide a hook for setting the name of a task...
>> ideally I would like task names to be set to some sensible defaults,
>> like the class name of a (and often the only) component assigned to
>> it. I have no idea how hard this is...
>
>
> If i remember, it is already done at the component level. In ocl, for
> instance, see /deployment/DeploymentComponent.cpp in setNamedActivity around
> line 1969. For standard case, it instanciate an RTT::Activity by passing the
> component name. In rtt, rtt/Activity.cpp there is 1-1 mapping between the
> activity and the thread so the thread can be named according to the
> activity.
>
> The same thing could be done for the non periodic activity, but for an
> unknown reason, the name of the component isn't passed to the Activity ctor
> :(. It could be a trivial patch IMHO.
>
> For other kind of activities, its less easy to solve the naming of
> threads...
>
>
>
>
>>
>> 2. pthread_setname_np is a newer, ultimately, more portable way to set
>> the thread names; seems like it will be standardized POSIX if its not
>> already...
>
>
> Yes, i also prefer the pthread_setname_np. But i let the comment with
> alternative solution.
>
>
>>
>> The LTTNG suite looks interesting... sounds like these tools are
>> combining userspace debugger-like functionality (that are aware of the
>> C,C++ symbols, hopefully), with tracing at the kernel level...
>
>
> I also look for tools that could generate these kind of diagrams for strace
> outpouts... If you know some project related to this subject, i'm
> interested.
>
>>
>> Cheers,
>> Andrew
>
>
> Cheers,
> Paul.
>
>
>
>>
>> On Tue, Oct 29, 2013 at 10:20 PM, Paul Chavent <paul [dot] chavent [..] ...>
>> wrote:
>>>
>>> Hi Andrew,
>>>
>>> Some time ago, i wrote a patch
>>> (http://bugs.orocos.org/show_bug.cgi?id=1016) that allow to name threads. If
>>> you map one thread per task, it allow to see all your tasks when you call
>>> "top -H -p <pid>"...
>>>
>>> This work was done in order to use the lttng suite in order to trace my
>>> program.
>>>
>>> lttng allow to trace program (see userspace tracer http://lttng.org/ust)
>>> with a small overhead, then trace plots (http://lttng.org/eclipse).
>>>
>>> I didn't managed to import my trace in eclipse the last time i tried, but
>>> the support on the mailing list was very reactive...
>>>
>>> If you are interested, let me know. I will post more information, or even
>>> write a little page on the wiki.
>>>
>>> Regards.
>>>
>>> Paul.
>>>
>>>
>>> On 10/29/2013 10:18 AM, Andrew Wagner wrote:
>>>>
>>>> Update: Here's another example of the sort of plot that I lust after
>>>> (the last one):
>>>>
>>>>
>>>> http://www.mathworks.nl/products/xpctarget/examples.html?file=/products/...
>>>>
>>>>
>>>> Does anyone know of something like that is available for linux
>>>> threads? I'm not sure if orocos or the components even have enough
>>>> information to generate diagrams of when they were pre-empted by what.
>>>> Perhaps there is general purpose linux kernel profiling software that
>>>> could log the data needed for this diagram? i.e. some tool that I
>>>> feed the relevant PID's for the threads that I care about, and hooks
>>>> in to the scheduler to log when they were active on which cores....
>>>>
>>>> We're now running linux 3.4 with the PREEMPT RT patches (installed
>>>> from a package provided by some audio guy) if it matters:
>>>>
>>>> $ uname -a
>>>> Linux planepower-pc 3.4.29-rt41 #2 SMP PREEMPT RT Sun Feb 10 21:19:29
>>>> CET 2013 x86_64 x86_64 x86_64 GNU/Linux
>>>>
>>>> On Fri, May 31, 2013 at 1:42 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>>> wrote:
>>>>>
>>>>> On 05/31/2013 01:25 PM, Andrew Wagner wrote:
>>>>>>
>>>>>> Hi Sylvain, thanks for the suggestion, but we don't want ROS or Rock
>>>>>> or any other meta-operating system as a dependency of our flight code.
>>>>>> Since nobody is currently maintaining a git repo for the whole
>>>>>> toolchain that you can just check out and build, we ~do use the
>>>>>> bootstrap_linux script to get a working orocos toolchain, but that's
>>>>>> it.
>>>>>
>>>>> FYI, given that you already have an orocos toolchain, the only things
>>>>> you would need additionally to get a full logger with base::Time would
>>>>> be:
>>>>>
>>>>> base/types: pure CMake package, no additional dependencies
>>>>> base/orogen/types: oroGen (you need an orogen generation step +
>>>>> then
>>>>> normal CMake compilation). No additional dependencies
>>>>> tools/logger: oroGen (you need an orogen generation step + then
>>>>> normal
>>>>> CMake compilation). No additional dependencies
>>>>> tools/pocolog: pure ruby (add pocolog/lib to RUBYLIB and
>>>>> pocolog/bin
>>>>> to PATH). No additional dependencies
>>>>>
>>>>> --
>>>>> Sylvain Joyeux (Dr.Ing.)
>>>>> Senior Researcher
>>>>>
>>>>> Space & Security Robotics
>>>>> Underwater Robotics
>>>>>
>>>>> !!! Achtung, neue Telefonnummer!!!
>>>>>
>>>>> Standort Bremen:
>>>>> DFKI GmbH
>>>>> Robotics Innovation Center
>>>>> Robert-Hooke-Straße 5
>>>>> 28359 Bremen, Germany
>>>>>
>>>>> Phone: +49 (0)421 178-454136
>>>>> Fax: +49 (0)421 218-454150
>>>>> E-Mail: robotik [..] ...
>>>>>
>>>>> Weitere Informationen: http://www.dfki.de/robotik
>>>>> -----------------------------------------------------------------------
>>>>> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
>>>>> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
>>>>> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
>>>>> (Vorsitzender) Dr. Walter Olthoff
>>>>> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
>>>>> Amtsgericht Kaiserslautern, HRB 2313
>>>>> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
>>>>> USt-Id.Nr.: DE 148646973
>>>>> Steuernummer: 19/673/0060/3
>>>>> -----------------------------------------------------------------------
>>>>>
>>>>> --
>>>>> Orocos-Users mailing list
>>>>> Orocos-Users [..] ...
>>>>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>>
>>>
>>> --
>>> Orocos-Users mailing list
>>> Orocos-Users [..] ...
>>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>
>>
>