Comment 3 for bug 1748781

So looking through the code, one thing comes to mind. If the channel under
Changes() was closed, then I think the loop would wake up, but only see an
empty list, and thus would issue no Get() requests and thus never find an
error and just loop calling Changes() over and over.
Theoretically if Changes was closed it should be trying to kill the tomb so
the Dying side should trigger and shut down. But if we missed that, there
is nothing in this loop that would notice an error.

My main concern is if this is actually a general design failure and we need
to be changing our loops from

select
...
case val <-Changes():

to
case val, ok <-Changes():
if !ok {
  return Error("changes channel closed")

John
=:->

On Feb 11, 2018 23:30, "John A Meinel" <email address hidden> wrote:

> This is the SVG of cpu time spent.
>
>
> ** Attachment added: "profile002.svg"
> https://bugs.launchpad.net/juju/+bug/1748781/+attachment/
> 5053182/+files/profile002.svg
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1748781
>
> Title:
> processModelRemovals stuck in a loop
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1748781/+subscriptions
>