Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@wins.uva.nl>
To: msnyder@cygnus.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH RFA] Clean up spurious SIGSTOPS in lin-lwp
Date: Sat, 26 May 2001 02:15:00 -0000	[thread overview]
Message-ID: <200105260915.f4Q9Fik00295@delius.kettenis.local> (raw)
In-Reply-To: <3B0EE363.DA047C1B@cygnus.com>

   Date: Fri, 25 May 2001 15:57:39 -0700
   From: Michael Snyder <msnyder@cygnus.com>

   Mark, 

   This patch will get rid of most of those "Delayed SIGSTOP" messages, 
   so that lin_lwp_wait will rarely if ever get a SIGSTOP that was generated
   by gdb.  It entails three basic changes:

    * In lin_lwp_attach_lwp, consume the SIGSTOP that is generated by
      PTHREAD_ATTACH.
    * In stop_wait_callback, try again to consume the SIGSTOP after
      "pushing back" a SIGTRAP for a thread other than the event thread.
    * Similarly try again to consume a SIGSTOP after tossing away a
      redundant SIGINT.

In principle the current approach saves us a few system calls, at the
risk of a GDB-generated SIGSTOP colliding with a SIGSTOP that wasn't
generated by GDB.

I assume you're trying to make GDB behave a little better when some
outside agency is generating SIGSTOPs.  We have to keep in mind that
as long as SIGSTOP doesn't have Real-Time semantics, we can never
guarantee that things work entirely reliably.  The question is whether
we prefer the situation where things clearly don't work correctly if
SIGSTOP is used in the user program (as we have now, although I'm not
sure about that "clearly"), or that we'd rather have things more or
less working correctly, but fail in some corner cases only.

The change to lin_lwp_attach_lwp is a change from

  for every thread
    send out message
  for every thread
    collect response

to 

  for every thread
    send out message
    collect response

In theory this could make the process slower, making attaching even
more non-atomic than it is already.  But we hardly ever attach to more
than one or two LWP's at the same time (only when attaching to an
already running threaded program) so that shouldn't really matter.  So
if this change represents a real improvement in GDB's behaviour I
think it's OK.

Mark


  reply	other threads:[~2001-05-26  2:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-25 15:57 Michael Snyder
2001-05-26  2:15 ` Mark Kettenis [this message]
2001-05-30 16:03   ` Michael Snyder

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=200105260915.f4Q9Fik00295@delius.kettenis.local \
    --to=kettenis@wins.uva.nl \
    --cc=gdb-patches@sources.redhat.com \
    --cc=msnyder@cygnus.com \
    /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