Re: comments about jsonrpc.el

[Filipp Gunbin]

João,

On 02/06/2018 01:42 +0100, João Távora wrote:

>> 2) When deferred action runs, it invokes jsonrpc-async-request which
>> invokes jsonrpc-connection-send.  I think we should also clear
>> deferred actions here (why leave them?).
>
> You mean *all* deferred actions? I believe the right thing to do is to
> clear the one that is about to run, since the other ones may be
> subject to other conditions.

If they are independent of each other - then yes, probably only the one
which runs.

>> Also, there seem to be two ways to handle timer: a) take timer from
>> deferred action and save it in continuation - then its timeout spans
>> both 'wait until server ready' interval and actual response wait
>> interval; b) cancel deferred action timer and create new timer - it's
>> done in the current code.
>
> No, it is (a) that is done, because we store the timer as the second
> element in (FN TIMER ID) pointed to by the deferred action. And we don't
> re-create the timer.

But line 643 says '(setq timer (funcall make-timer)))' - isn't it what
gets into continuation?  To be clear - I mean the timer which gets into
continuation (but if we re-defer deferred action - then yes, the
deferred action's timer is "inherited").

>> 3) When deferred action runs, jsonrpc--async-request-1 should be
>> called with 'deferred' non-nil - so it actually sends request.  But
>> it's unclear to me how this deferred=t is passed there ('apply' call
>> on line 621)
>
> A call to jsonrpc--async-request-1 that defers itself is always ends up
> being called again with the very same arguments. It is the
> jsonrpc-connection-ready-p predicate that decides it the action runs.

I'm just not familiar with cl-defun enough, sorry.  If '&rest args'
includes 'deferred' in 'args', then ok.

Thanks!
Filipp