This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: debugging threads vs processes
- To: "'Cedric Berger'" <cedric at wireless-networks dot com>, "Boehm, Hans" <hans_boehm at hp dot com>
- Subject: RE: debugging threads vs processes
- From: "Boehm, Hans" <hans_boehm at hp dot com>
- Date: Fri, 13 Jul 2001 13:08:17 -0700
- Cc: "'tromey at redhat dot com'" <tromey at redhat dot com>, jpolsonaz at mac dot com, Jeff Sturm <jsturm at one-point dot com>, Per Bothner <per at bothner dot com>, java-discuss at sources dot redhat dot com
> -----Original Message-----
> From: Cedric Berger [mailto:cedric@wireless-networks.com]
> There is clearly good things with LinuxThreads (i.e. simplicity, ...)
> But as long as, at least...
> - top
> - ps
> - kill
> - gdb
>
> ... are not fixed, and to not really understand the
> difference between a thread
> and a process, using multithreaded application in Linux will
> remain a huge pain.
>
I think some of this depends on what you're used to. I've adapted to the
top and ps behavior, and I often find it useful that I can see the threads
separately. If it automagically told me whether something was the main
thread, the manager, or another thread, that would be better still. If it
showed me only processes, I'd be less happy. I'm not sure what the various
standards have to say about this behavior, and that may indeed be a problem.
Gdb is different, in that it does try to understand threads, and its
attempts have mostly been getting more successful over time. As I
understand it, there is a fair amount of infratstructure in linuxthreads to
support gdb. Gdb seems to do fine at switching between and examining
multiple thread stacks, for example. It's just that it still has some bugs,
including apparently waking up some blocked threads when it shouldn't.
Hans