[Development] Work on qDebug and friends
bm_witness at yahoo.com
Mon Feb 6 16:07:26 CET 2012
> From: David Faure <faure at kde.org>
> To: development at qt-project.org; Diego Iastrubni <diegoiast at gmail.com>
> Sent: Sunday, February 5, 2012 5:54 PM
> Subject: Re: [Development] Work on qDebug and friends
> On Sunday 05 February 2012 10:50:48 BRM wrote:
>> > From: Diego Iastrubni <diegoiast at gmail.com>
>> >On Fri, Feb 3, 2012 at 1:10 PM, David Faure <faure at kde.org>
>> >Once this goes in I'll add support for %pid%, %processname% and
>> >>and we'll be all set :)
>> >You meant %threadid% of course... right?
>> Wouldn't having both available be useful?
> Yes, the PID is definitely what I meant, it's very much needed, for the case
> of multiple
> daemons running in the background and outputting debug into the same file. The
> is then useful for killing a run-away daemon, or for attaching gdb to it, etc.
> Without the PID, impossible to notice that these two lines come from two
> processes, for instance:
> 20:29:11 konqueror(2630) kdemain: Unknown class "" in session saved
> 20:29:11 konqueror(2625)
All true; but it would also be useful to the Thread ID available as well - so you can tell the difference between what's provided in two different threads.
I know Linux 2.4 LWPT simply did different processes; but that's not true with 2.6; and I believe Windows uses separate IDs as well.
True - the user could care less; but it would be useful for debugging.
For example, a single program with multiple data streams where each data stream is handled by its own thread (e.g. a server daemon).
Without the thread ID as well, how would you track down thread related bugs? (Yes, for a server application you should be doing some kind of session id as well;
but if those data streams were with files or sockets, or something then you may not have an easy way to distinguish the threads based on the use alone.)
More information about the Development