Community
Participate
Working Groups
From bug 355828 comment 4: > > I was thinking that we do want some persistence about thread filters. If the > > user limits a breakpoint to some threads, re-launching the program should have > > the breakpoint still limited to the threads. > > Is this possible in the general case? > > We know that GDB will number threads in the order that it comes across them. We > cannot assume that the target operating system will provide a thread name or > thread ID which is both unique and constant across multiple launches. Some > threads may not be created on every launch. Some applications may create large > numbers of short-lived threads over time. In the simple scenario I had imagined, the program was creating the threads always in the same order, so GDB would give the same id. But you are right that this may not always be the case, and a breakpoint that makes sense for thread 10 of one run, may be relevant to thread 11 on the next run. So, it would seem that with our current scheme, persistence is not really possible. I personally feel that having to reset the thread filters each time is not user-friendly. We should have a more deterministic scheme for the filter. For example, using a user-given name to identify the threads (if such a name exists for the thread).
From bug 355828 comment 5 Mikhail wrote: "> CDI does not seem to have such persistence. > > Any opinions on if we should try to persist the filter or not? I vote for > trying to persist. +1. I didn't do that for CDI because I thought that persisting thread ids could be confusing."
