Re: [PATCH RFA] process/thread/lwp identifier mega-patch

[Andrew Cagney <ac131313 at cygnus dot com>]

Kevin Buettner wrote:
> 

> > Have you considered ignoring the problem?  Well actually just
> > accumulating a list of all the created threads and then, when GDB
> > re-starts a target, deleting the lot?  Yes, this will clearly not scale
> > well in an application that creates then deletes millions of threads.
> > Hopefully though, the benefits (such as improved performance) of having
> > per thread objects will far out way this.

> I think that your suggestion could be made to work, though it won't
> be as simple as merely wiping out the thread list when GDB restarts
> a target.  The reason?  Dangling pointers in static globals.
> 
> E.g, in infrun.c, we have the following declaration:
> 
>         static int static int previous_inferior_pid;

ARRG!

> My patches change this declaration to:
> 
>         static struct ptid *previous_inferior_ptid;
> 
> We would need to make sure this (and other static globals) are
> reinitialized when the thread list is wiped out.

Really nasty would be to enter each of those globals into a database and
trash them at the same time as the thread pool is trashed.

It might even be a tolerable workaround since those globals will
eventually need to be deleted.

> Another alternative is to make the execution context identifiers (or
> ECIs for short) ``struct ptid'' instead of ``struct ptid *''.  I.e,
> make the ECI a struct instead of a pointer to a struct.  The problem
> with doing this is that the ECI's type can no longer be opaque.

Again as an imtermediate step yes.

> One can argue that if GDB accesses a defunct ECI (regardless of
> implementation) at all, it is behaving incorrectly, because this
> behavior is wrong regardless of whether the ECI is a struct or a
> dangling pointer.  It's just that it could be catastrophic if it's the
> latter...
> 
> So maybe it'd be best if we make sure that each and every ECI
> occurence in the code is initialized properly when the thread list is
> cleaned up.  (In other words, I'm coming around to liking your
> suggestion again...)

You should probably look carefully at
http://sources.redhat.com/ml/gdb/2001-02/msg00210.html .  In that
diagram, ``context'' roughly correspond to ``struct ptid *''.

	Andrew