This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] fork in multi-threaded apps, per-thread pending_fork, other follow-fork cleanups.
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Cc: Joel Brobecker <brobecker at adacore dot com>
- Date: Wed, 10 Jun 2009 22:57:03 +0100
- Subject: Re: [RFC] fork in multi-threaded apps, per-thread pending_fork, other follow-fork cleanups.
- References: <200905192237.48639.pedro@codesourcery.com> <20090608142154.GA7446@adacore.com>
On Monday 08 June 2009 15:21:54, Joel Brobecker wrote:
> > So, what to do? One way to go about this, is to detect that
> > the user switched threads, since the fork event was reported, follow
> > the child, and refuse to resume it, leaving up to the user to
> > decide what to do with it:
>
> FWIW, I'm a little late in answering, but the behavior seems reasonable
> to me. I'd personally hate the debugger switching threads from under me
> without giving me the option of canceling my operation.
>
> > warning: Not resuming: switched threads before following fork child.
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> I do find the message a little terse as to what is going on, and why
> the resume was aborted. I wonder if we can be a little more explicit?
There's always room for improvement. :-)
> Is there a way for the user to determine which thread to switch back
> to in order to be able to resume?
It's too late for that, the fork has already been followed by then. I
thought that forcing the user to select the forking thread before
resuming wouldn't be a nice experience (and considering an IDE, may be
awkward), but I may be wrong, and can be convinced otherwise. If you
think that's preferred, we can tweak it.
--
Pedro Alves