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

Daniel Jacobowitz
2008-07-01T14:03:38Z

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:
> > > - In non-stop mode, the current thread may exit while the
> > > user has it selected. Switching current thread, and restoring
> > > it with a cleanup is problematic in non-stop mode.
> >
> > The target interface is async, the inferior program is running - but
> > GDB retains a single thread of control. So unless the inferior runs
> > while the cleanup is live, there's no problem here. I suppose it
> > could be trouble if you enter the expression evaluator, though?
>
> Sure it can run while the cleanup is live. It could already be
> running when the cleanup was created. Remember that the selected
> thread may be running at any time.

Doesn't matter if the thread is already running. We won't go looking
for events while normal cleanups are on the stack in most cases - so
even if the thread exits, we won't remove it from the thread list
until later. But the evaluator, and some commands, might cause us to
return to w_f_i. That's all I meant.

> The user loses the selected frame in thread 1, because when
> the cleanup is ran, the thread is running/stepping.
> Since the thread stepped into another frame, we could
> claim that since the originally selected frame is still live,
> it should still be selected. But, it can also be
> claimed that, though luck, the thread was set running,
> you lose the selected frame. This doesn't seem
> like an important enough case to care about. Agree?

Agreed. We can worry about it later. Execution commands in commands
lists already behave weirdly - e.g. they may cause the rest of the
command list to be discarded.

> 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 :-)

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

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?

--
Daniel Jacobowitz
CodeSourcery