Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Nick Roberts <nickrob@snap.net.nz>
Cc: gdb@sources.redhat.com
Subject: Re: Merge of nickrob-async-20060513 to mainline?
Date: Wed, 30 Aug 2006 21:43:00 -0000	[thread overview]
Message-ID: <20060830214257.GA5397@nevyn.them.org> (raw)
In-Reply-To: <17654.994.815362.897653@kahikatea.snap.net.nz>

On Thu, Aug 31, 2006 at 09:32:18AM +1200, Nick Roberts wrote:
>  > Just generate the diff between your mergepoint and branch, and then
>  > pipe it to diffstat, assuming you've got it installed.
> 
> Doing:
> 
> cvs diff -r nickrob-async-20060828-mergepoint gdb | diffstat
> 
> from the src directory gives the output below.

Not too bad.

>  > Well, I meant from an internals perspective - like, a patch just
>  > summarizing the interface changes, if the whole patch is too big to
>  > post at once.
> 
> Instead of GDB waiting for the enferior to stop directly, it creates a signal
> thread to do that.  This means that the main thread can continue to process the
> event loop.  When the inferior does stop, the signal thread writes to a file
> which GDB detects through handle_file_event in the event loop. It then calls
> inferior_event_handler.

OK, this is easily mimicable without threads, at least on GNU/Linux.

On Cygwin/Windows I imagine we'd want to use threads, but the tradeoffs
there are somewhat different :-)

>  > > Also it still uses pthreads.  You said previously that it should be done
>  > > in one process and, following a remark from Jim Ingham, that ptrace is
>  > > non-blocking.  AFAICS the problem is that wait *is* blocking and I can't
>  > > see of a way to deal with that without using another thread.
>  > 
>  > Ah, but wait is non-blocking.  You have to (A) use WNOHANG, and (B) be
>  > careful to handle asynchronous SIGCHLD events.  It's not especially
>  > difficult, I don't think, but the async event loop in gdb has always
>  > confused me; we'll have to figure out how to gather up sigchld/wait
>  > events.
> 
> The manpage just says:
> 
>        WNOHANG
>               return immediately if no child has exited.
> 
> but what value does it return with?  Does GDB ignore SIGCHLD events so it
> can detect state changes through wait?

If that's all it says I recommend a better man page :-)

       waitpid(): on success, returns the process ID of the child whose
       state has changed; on error, -1 is returned; if WNOHANG was
       specified and no child(ren) specified by pid has yet changed
       state, then 0 is returned.

Different ports of GDB treat SIGCHLD differently.  linux-nat.c, for
instance, blocks it so that it can use sigsuspend.  Instead, we would
have to register handlers for sigchld events somehow (probably using
the same infrastructure used for SIGINT to quit operations).

I can work on this, though not right away.

-- 
Daniel Jacobowitz
CodeSourcery


  reply	other threads:[~2006-08-30 21:43 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-30  2:27 Nick Roberts
2006-08-30  2:33 ` Daniel Jacobowitz
2006-08-30  3:21   ` Nick Roberts
2006-08-30  4:01     ` Daniel Jacobowitz
2006-08-30 12:31       ` Eli Zaretskii
2006-08-30 21:34       ` Nick Roberts
2006-08-30 21:43         ` Daniel Jacobowitz [this message]
2006-08-30 23:45           ` Nick Roberts
2006-09-26  8:41           ` Nick Roberts
2006-09-26 12:38             ` Daniel Jacobowitz
2006-09-26 22:12               ` Nick Roberts
2006-09-26 22:24                 ` Daniel Jacobowitz
2006-09-26 23:40                   ` Nick Roberts
2006-09-29  1:50                   ` Nick Roberts
2006-10-06  0:53               ` Nick Roberts
2006-10-06  1:26                 ` Daniel Jacobowitz
2006-10-06  2:13                   ` Nick Roberts
2006-10-06  3:24                     ` Daniel Jacobowitz
2006-10-08  3:46                       ` Nick Roberts
2006-10-09 18:00                         ` async implies sync, was " Michael Snyder
2006-10-09 20:28                           ` async implies sync Nick Roberts
2006-08-31 21:03     ` Merge of nickrob-async-20060513 to mainline? Mark Kettenis
2006-08-31 21:49       ` Nick Roberts
2006-08-31 22:29         ` Daniel Jacobowitz
2006-08-31 22:40           ` Nick Roberts
2006-08-31 22:53             ` Michael Snyder
2006-08-31 23:33               ` Nick Roberts
2006-08-31 23:37                 ` Daniel Jacobowitz
2006-08-31 23:59                   ` Jim Ingham

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=20060830214257.GA5397@nevyn.them.org \
    --to=drow@false.org \
    --cc=gdb@sources.redhat.com \
    --cc=nickrob@snap.net.nz \
    /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