threadname support in KDevelop 4

Albert Zeyer albert.zeyer at
Fri Dec 18 00:23:46 UTC 2009


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 

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 );

The diff to revision 1063234 is attached. But it is mostly thought as a 
demonstration, the way I am handing the thread names over to the frame stack 
model is not really the nicest way... (But it also seems that the frame stack 
model was never really designed with that case in mind.) But it works great 

See some screenshot here:

So, I am really interested in what you think about that. Or in what way (that 
is realistic to be useable soon) you would implement thread-name support.

- Albert
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: samplecode.cpp
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdev4-threadnames.diff
Type: text/x-patch
Size: 4853 bytes
Desc: not available
URL: <>

More information about the KDevelop-devel mailing list