bug#9087: Crash reading from minibuffer with icomplete-mode

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: rudalics@gmx.at,  claudio.bley@gmail.com,  lekktu@gmail.com,  9087@debbugs.gnu.org
> Date: Fri, 06 Jan 2012 19:42:24 -0500
> 
> > I can avoid the crash with the patch below.  But it defers the
> > throwing until Emacs is done whatever it was doing (in this case,
> > evaluating byte code).  Is this acceptable?
> 
> Is a C-g also delayed in a similar way under w32?

Yes, it is, at least in this case.  The only difference between
handling of throw-on-input and C-g on Windows is that the latter can
also interrupt prolonged system calls.  But throw-on-input is not
supposed to do that, right?  And we are not in a system call in this
case, we are just in a long calculation done by byte code.

Jason, could you please chime in?  signal_user_input was written by
you.  Doing a QUIT from a thread other than the Lisp evaluation thread
is clearly not TRT, I think, so it must be taken out.  The question
is: is there some way we can honor immediate_quit here, or should we
just ignore it?  TIA.

(Once again, why isn't throw-on-input documented?  With only a short
doc string lacking any details, I have no way of knowing what exactly
its contract is.)