threadname support in KDevelop 4

Vladimir Prus ghost at
Sun Dec 20 08:35:32 UTC 2009

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]; }
- Volodya

More information about the KDevelop-devel mailing list