Excellent, thanks for persisting on this!
I think your second idea sounds less error prone than having to figure out
whether the cache is trustworthy at a particular point. Maybe even better than
triggering off a stop event is to clear the caches before we do whatever might
make the threads in
The ThreadPlanStack always has one base thread plan. You can't get rid of that
one, the system relies on its always being there. Despite it's name,
DiscardThreadPlans doesn't actually discard all the thread plans, just all but
the base thread plan... So I think that's neither here nor there..
I've tried to find a way to move the calls the way you mentioned, but it
doesn't seem trivial.
Some more information:
- The invocation to the thread plan is done by Thread::ShouldStop, where it
does
```
// We're starting from the base plan, so just let it decide;
if (current_plan->IsBasePlan(
> On Jan 21, 2021, at 2:33 PM, Jim Ingham wrote:
>
>
>
>> On Jan 21, 2021, at 12:51 PM, walter erquinigo via Phabricator
>> wrote:
>>
>> wallace added a comment.
>>
>> Sorry for returning late to this diff, but I have some additional
>> information. This is what's happening:
>>
>> - Bef
> On Jan 21, 2021, at 12:51 PM, walter erquinigo via Phabricator
> wrote:
>
> wallace added a comment.
>
> Sorry for returning late to this diff, but I have some additional
> information. This is what's happening:
>
> - Before the exec, the base thread plan holds a reference to the thread
Thanks for looking into this further! The thing to figure out is who still has
a reference to either the Thread * or to the ThreadPlanStack over the
destruction of the thread. That shouldn't be allowed to happen.
Jim
> On Jan 11, 2021, at 10:01 PM, walter erquinigo via Phabricator
> wrote:
