From: Eric Paire <paire@ri.silicomp.fr>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Mark Kettenis <kettenis@science.uva.nl>,
"H . J . Lu" <hjl@lucon.org>, GDB <gdb@sourceware.cygnus.com>
Subject: Re: Is the current gdb 5.1 broken for Linuxthreads?
Date: Thu, 20 Sep 2001 01:36:00 -0000 [thread overview]
Message-ID: <200109200836.f8K8a6p05580@mailhost.ri.silicomp.fr> (raw)
In-Reply-To: <3BA9025B.9080302@cygnus.com>
> > I already started a thread to explain that that stopping all threads in
> > a synchronous way was an illusion: Think of a 2-way processor on which
> > 2 threads are running on each processor: If one thread stops, the time
> > required by one processor to handle the trap, discover that others
> > threads must be stopped, makwe the interprocessor request, ... allows
> > the other thread to run thousands of instructions on the second
> > processor before being stopped. The result is that you think all threads
> > have stopped at the same time, while it's false, even if you have the best
> > interface you can think of.
>
> Just an aside, everyone will agree with your point that synchronized
> thread stop model is an illusion. However, that doesn't make the
> model/illusion wrong. Most other systems still make a synchronised halt
> interface available since it is simple and fast - the complexity of
> having to suspend all related threads being constrained to the kernel.
>
From the user point of view, it seems simple and fast. From the kernel
point of view, this is somewhat difficult to achieve (I already had to deal
with when I worked on OSF/MACH3.0), particularly on multi-processors
(on uniprocessors, all threads but the current one are not in running
state, while on MP, some of them may be in running state on other
processors). IMHO, although I admit that this is not very easy, we can
nevertheless stop all threads individually with SIGSTOP, so that I do
not see why we should add complexity in the kernel to simplify something
we can already do in the user space (and certainly, Linus doesn't for now).
There is another difficulty on Linux which seems much more important than
these ones. There is no support for MT core dumps. As Linus has always
refused to add such functionality in the kernel (which is somewhat similar
with your simple interface to stop all threads), a solution should be though
of in the user space.
-Eric
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Eric PAIRE
Web : http://www.ri.silicomp.com/~paire | Groupe SILICOMP - Research Institute
Email: eric.paire@ri.silicomp.com | 2, avenue de Vignate
Phone: +33 (0) 476 63 48 71 | F-38610 Gieres
Fax : +33 (0) 476 51 05 32 | FRANCE
next prev parent reply other threads:[~2001-09-20 1:36 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-17 12:47 H . J . Lu
[not found] ` <20010917161350.A25349@lucon.org>
2001-09-17 19:13 ` H . J . Lu
2001-09-18 13:56 ` H . J . Lu
2001-09-18 15:22 ` RFC: Fix gdb 5.1 for Linuxthreads H . J . Lu
2001-09-19 5:42 ` Duncan Palmer
2001-09-19 9:19 ` H . J . Lu
2001-09-20 8:21 ` Duncan Palmer
2001-09-19 7:06 ` Mark Kettenis
2001-09-19 8:58 ` H . J . Lu
2001-09-19 0:46 ` Is the current gdb 5.1 broken for Linuxthreads? Eli Zaretskii
2001-09-19 8:43 ` H . J . Lu
2001-09-19 6:56 ` Mark Kettenis
2001-09-19 7:39 ` Eric Paire
2001-09-19 9:05 ` H . J . Lu
2001-09-20 0:59 ` Eric Paire
2001-09-19 13:39 ` Andrew Cagney
2001-09-20 1:36 ` Eric Paire [this message]
2001-09-20 8:03 ` H . J . Lu
2001-09-20 21:49 ` Eric Paire
2001-09-19 9:10 ` H . J . Lu
2001-09-19 6:32 ` Mark Kettenis
2001-09-19 9:16 ` H . J . Lu
2001-09-21 2:27 James Cownie
2001-09-21 5:04 ` Eric Paire
2001-09-21 5:25 ` James Cownie
2001-09-21 8:35 ` H . J . Lu
2001-09-21 8:39 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200109200836.f8K8a6p05580@mailhost.ri.silicomp.fr \
--to=paire@ri.silicomp.fr \
--cc=ac131313@cygnus.com \
--cc=gdb@sourceware.cygnus.com \
--cc=hjl@lucon.org \
--cc=kettenis@science.uva.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox