bug#6585: 23.1; Hang / CPU 100% on background interaction when in minibuffer

[martin rudalics]

> Now, if start == (selected-window) is the minibuffer, then it should be
> clear that current == (next-window ... 'no-minibuffer ...) will never
> result in (eq start current).  And if the buffer that is passed in isn't
> visible then (not found) will never be nil and we are stuck in an
> infinite loop.

Using `next-window' to find all windows is generally unsafe since
windows might get created and deleted in between (in particular the one
you named `start').  Always use `window-list' instead.  The doc-string
of `next-window'

  If you use consistent values for MINIBUF and ALL-FRAMES, you can use
  `next-window' to iterate through the entire cycle of acceptable
  windows, eventually ending up back at the window you started with.

is IMHO misleading in this regard.

> So this part is not an emacs problem at all.  But I am puzzled as to why
> if this is byte-compiled I can't C-g and break out of this.
>
> I'll fix my code and then the problem goes away.  So if you want to
> consider this "not-a-bug", ok.  But shouldn't C-g work here?

C-g should work.  If it doesn't we have a bug.  IIUC the only occurrence
of `switch-to-buffer' is ifdefd out in the source code so there can't be
any harm from an inhibit-quitted call from C.  Could you try to run Emacs
in the debugger to find out where it hangs?  Or post a self-contained
emacs -Q based recipe here?

martin