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

[martin rudalics <rudalics@gmx.at>]

 > 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