linux specific dev issues

[mcmanus at AppliedTheory.com (Patrick McManus)]

blu crew,

I've run into some linux specific development issues the last couple
of days, both involving threads. I'm going to toss one out to the
group for your input, and I have an answer (though not a good one) to
the second one that I'll share as an fyi.

My application creates threads to handle some of its
events.. typically they live for a couple seconds and die and are
joined. Over a long period of time, I can make a lot of threads ;)

Issue 1 Profiling:

gprof gets the call graph right for all of the threads in terms of
number of invocations, but it doesn't get the CPU time for anything
that happens in anything other than the original thread. (that is it
knows how many times a thread invoked foo() but it has no idea how
many resources foo() consumed unless it was invoked by the original
thread)..

Any pointers folks have to reasonable linux thread profiling are
welcome.

A related issue, getrusage() stores its info for the thread CPU usage
(in aggregate, not helpful enough for me) under RUSAGE_CHILDREN
instead of RUSAGE_SELF. This is different than most other OS's. (where
threads are part of the same process).

Which brings me to the "all processes are really threads in linux,
with fork() implemented as a funky clone() that dups more than the
stack w/Instruction Pointer".. can anybody provide insight into this design
choice? It seems to provide a lot of confusion on the difference
between a process and a thread in various development tools. (gprof as
case in point).

Issue 2 GDB and exited threads:

suffice it to say that GDB up to and including version 5.0 doesn't
acknowledge the termination of a lin-thread. When a thread exits and
is joined (the process equivalent of sigchld being caught) the thread
remains in the process table (there's that odd overlap.. 2 threads of
the same process with different getpid() vals.. wacky.) as a zombie.

at some point you can't create more threads cause you've got too many
zombies, and no way to clean them up (when running in gdb).. that
limits the usefulness of gdb in this context.

the gdb crew is hoping to fix this for 5.1... but I know a bunch of
people who've been confused by it, so this seemed like the place to
write it down ;)

Thanks.

-Patrick




-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).