Re: froggy/archer -- 2009-02-24

[Daniel Jacobowitz <drow at false dot org>]

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