Re: [non-stop] 10/10 split user/internal threads

[Pedro Alves <pedro@codesourcery.com>]

A Tuesday 01 July 2008 15:03:11, Daniel Jacobowitz wrote:
> On Tue, Jul 01, 2008 at 02:37:44PM +0100, Pedro Alves wrote:
> > A Tuesday 01 July 2008 01:51:28, Daniel Jacobowitz wrote:
> > > On Mon, Jun 30, 2008 at 01:08:48AM +0100, Pedro Alves wrote:
> > There's one issue that I'd like to point out.  That is, is a
> > thread exits, and it was inferior_ptid, we can't just switch
> > inferior_ptid to null_ptid as I could with split user/internal
> > threads split.  A *lot* of things break.
> >
> > The issue arises with the OS quickly reusing ptids:
> >
> >   - inferior_ptid (ptid1) exits, we can't delete it from the
> >     thread list yet (things break, e.g. context switching...,
> >     but many other things break in target code.)
> >   - We mark it with THREAD_EXITED, but leave it there.
> >   - target notifies new thread with ptid1.  There's already
> >     such a thread in the list, and it's also the
> >     current thread -- inferior_ptid.
> >   - To add this new thread to the list, we must get rid
> >     of the old exited thread.  Conceptually, this new thread
> >     although it has the target identifier, it should have a
> >     new GDB thread id.  So, we could say that in this case,
> >     the "non-stop doesn't change threads" premise breaks.  But,
> >     then again, the user couldn't do anything to the exited
> >     thread anyway, and it can only exit is it is running, in which
> >     case the user also couldn't do most things with it.  Maybe we
> >     can just live with this exception.
>
> IMO, as long as GDB is not likely to crash, I don't think there's a
> big problem here.  If we, for instance, fail to report one pair of
> thread exit and thread creation events in this case that would be OK.
> Any number of other quirky behaviors would too.  Most systems have a
> sufficiently large ID space and avoid immediate reuse such that this
> is very unlikely to ever trigger.  If we come across a system that
> reuses the first available TID then we'll have to do better but we'll
> also have an easier way to test :-)
>

Well, quickly was perhaps a too much of a quick word.  If the user leaves
the selected thread pointing at an already exited thread, and the
app has many short lived threads, the reusing doesn't have to
be that quick.  I'd guess that we may see it happen no so unfrequently
if the target implements thread ids as pointers to (reused) thread
control blocks.

> Is this patch a blocking issue for the other non-stop patches, or
> would you like to start merging them?

I'd like to merge them, yes.  But I'd prefer to get the first 7
patches of the series checked in togheter.  I need another round of
review on patch 7 (and a mechanical follow up to it).

Patch 8 is going to request attention, and the new version of
patch 10 I'm about to post will need review.

Patches 1-6 and 9, you've already OKed.

> Also, a request: I know that you and Vlad are going to be filling in
> the documentation and test cases before any release goes out with this
> code.  In the meanwhile, could you create a wiki page listing things
> to be documented/tested so that there's a single central list?

I've created:
 http://sourceware.org/gdb/wiki/GDB_Next_Release
linked from the wiki frontpage.  It's short in content, but it should
prevent us from forgeting about it.

-- 
Pedro Alves