threadname support in KDevelop 4

[Vladimir Prus]

On Sunday 20 December 2009 15:57:03 Niko Sams wrote:

> On Sun, Dec 20, 2009 at 09:35, Vladimir Prus <ghost at cs.msu.su> wrote:
> > On Friday 18 December 2009 03:23:46 Albert Zeyer wrote:
> >
> >> Hi,
> >>
> >> I want to share some work/ideas/draft on threadname support in KDevelop 4.
> >>
> >> The first idea which came to my mind was to throw a signal and write a custom
> >> handler in KDevelop. This is by far not the nicest/cleanest way to do it but
> >> it is simple. You could do something similar already at the GDB level and pass
> >> the threadname over to KDevelop, which would be cleaner, but that would
> >> already complicate things up.
> >>
> >> Btw., this is also the same way MSVC is doing it. See the attached sample
> >> code.
> >>
> >> In this first demonstration, I tried to keep it as simple as possible. On
> >> KDevelop, I will check for SIGUSR1 and search in the thread receiving this
> >> signal for the first frame with a parameter called "name" and read that one.
> >>
> >> This is the core function on the app side:
> >>
> >> void setCurThreadName__signalraiser(const char* name) {
> >>       // this signal is only for debuggers, we should ignore it
> >>       signal( SIGUSR1, SIG_IGN );
> >>
> >>       // KDevelop will catch this, read the 'name' parameter and continue execution
> >>       raise( SIGUSR1 );
> >> }
> >
> > As I have said on #gdb, this is somewhat hacky approach. For starters, the
> > above code will break any application that uses SIGUSR1 for its own
> > purposes already.
> >
> > For another thing, as soon you you expect that application need to follow
> > a specific protocol to report the name of a thread, you can use a nicer
> > protocol, e.g:
> >
> >        std::map<pthread_t, const char*> names;
> >        void set_thread_name(const char *name)
> >        { names[pthread_self()] = strdup (name); };
> >    void thread_name(pthread_t t) { return names[t]; }
> 
> Imho this should be implemented on gdb side.
> Vladimir, do you think this would be realistic?
> 
> Perhaps using python that finds out the names without the need for
> this special function to the application?

IIUC, the problem is that in a typical pthread program, there are *no* names
of the threads, and pthreads do not provide an interface to set the name,
even.

- Volodya