From: Daniel Jacobowitz <drow@false.org>
To: archer@sourceware.org
Subject: Re: froggy/archer -- 2009-02-24
Date: Tue, 24 Feb 2009 16:46:00 -0000 [thread overview]
Message-ID: <20090224164601.GA13042@caradoc.them.org> (raw)
In-Reply-To: <49A42125.1050400@redhat.com>
On Tue, Feb 24, 2009 at 11:32:37AM -0500, Chris Moller wrote:
> The problem is that there are waitpid() instances in a lot of places,
> all of them blocking, and then dealing with whatever happens to break
> the block. The architecture of froggy is such that it expects to be the
> sole handler of inferior-process events that break waitpid() blocks on,
> and do so on a thread dedicated to that. So far as I can tell, the only
> way to make this work in existing gdb is to implement some other kind of
> blocking in the gdb waitpid()s and have froggy callbacks tickle them as
> necessary. This looks like it would not only be hard to do, but
> wouldn't really add any capability to what's there already.
I assume we're talking primarily about linux-nat.c.
The places which call waitpid (or my_waitpid) are:
* get_pending_events, which is using it to collect all events that
have happened asynchronously - using WNOHANG.
* linux_test_for_tracefork, which is just used at startup to
investigate capabilities of the host kernel.
* linux_child_follow_fork. This one does have to block, it's waiting
for the parent to stop as vfork returns.
* linux_nat_post_attach_wait, which is just trying to quiesce after
attach.
* linux_handle_extended_wait. This is another two-processes case;
we are waiting for the child to quiesce because we can not handle
the fork event reported by the parent until this happens.
* kill_wait_callback. Another ptrace wart; we're just waiting for
killed processes to go away. If we got async notification of
that, we could easily sleep here; the order doesn't matter.
* wait_lwp is also only used for quiescing, after stopping a thread.
And of course linux_nat_wait. This is the only really interesting
one; notice that in async mode, it never calls waitpid, just checks
the asynchronous queue.
Of course, I don't know what you're trying to achieve with froggy
here. But it sounds like it's doing basically the same thing as
the queued_waitpid / linux_nat_event_pipe_* mechanism; that is a
layer which transforms waitpid results into an async stream.
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2009-02-24 16:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-24 16:01 Chris Moller
2009-02-24 16:09 ` Daniel Jacobowitz
2009-02-24 16:24 ` Tom Tromey
2009-02-24 22:14 ` Chris Moller
2009-02-25 0:59 ` Tom Tromey
2009-02-25 11:05 ` Chris Moller
2009-02-25 16:30 ` Chris Moller
2009-02-24 16:32 ` Chris Moller
2009-02-24 16:46 ` Daniel Jacobowitz [this message]
2009-02-25 4:20 ` Chris Moller
2009-02-25 14:32 ` Jan Kratochvil
2009-02-25 15:11 ` Daniel Jacobowitz
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=20090224164601.GA13042@caradoc.them.org \
--to=drow@false.org \
--cc=archer@sourceware.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).