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

[João Távora]

João Távora <address@hidden> writes:

> 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

A quick followup to my question.  I did some more tests and it seems an
using unwind-protect fixes the issue.

   (unwind-protect
     (while (sit-for 30))
    (setq cancelled t)
    ...)

Without it, it seems multiple "sit-for" are entered without ever exiting
properly (properly = "executing through the (setq cancelled t)
instruction").  With it, every sit-for has a corresponding proper exit.

I don't understand the need for the "unwind-protect" and my question
stands.  Is the sit-for call silently quitting or what?  I don't see any
"Quit" in my *Messages* buffer and I'm not pressing C-g at any moment.
I bore down a little bit to keyboard.c's read_char() and it does have
some mentions of quitting, but I honestly don't know if I'm reading it
correctly...

João