A question regarding sit-for (and while-no-input)

["João Távora" <joaotavora@gmail.com>]

Hi,

In a couple of my extensions (jsonrpc.el and sly), I am using a
technique for synchronously fetching completion candidates from an
external process while still maintaining high responsiveness to the
user's input.

This is very useful for working with company.el, for example.  If the
user types the first few letters of a completion, the system goes to
work immediately fetching candidates.  If the candidates don't arrive in
time, they are silently discarded.

I am running into a bug in my program, which only happens sometimes and
is hard to reproduce.  I don't know how to fix it.

I hope this simplified snippet from the function jsonrpc-request in
lisp/jsonrpc.el illustrates the problem sufficiently for someone to
provide some hint as to what might be going askew:

   (let ((tag (some-unique-symbol))
         (cancelled nil))
     (catch tag
    ...
      (lambda (...) (unless cancelled (throw tag result-or-error)))
    ...
      (cond (cancel-on-input
             (while (sit-for 30))
             (setq cancelled t)
             `(cancelled ,cancel-on-input-retval))
            (t (while t (accept-process-output nil 30)))))
    ...
   )

'cancel-on-input' is a parameter to jsonrpc-request.  If the caller
provides it as 't', it means he/she wants that call to block as long as
there is no input from the user.  A response from the server before that
happens, which takes the form of a call to anonymous lambda, will also
cause the function to return.

Most of the time, this works flawlessly, as intended.  But the behaviour
I'm witnessing is that (throw tag) sometimes happens after the (catch
tag ...) has been torn down.

What am I missing?? If the catch has been torn down then surely (setq
cancelled t) must have run, right?  Otherwise I would be seeing an error
from sit-for, which I'm not.

Thanks,
João