unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "João Távora" <joaotavora@gmail.com>
To: emacs-devel <emacs-devel@gnu.org>
Subject: Re: run-with-timer vs run-with-idle-timer
Date: Fri, 11 May 2018 11:39:16 +0100	[thread overview]
Message-ID: <871seiqxwr.fsf@gmail.com> (raw)
In-Reply-To: <87603v4a5x.fsf@gnuvola.org> (Thien-Thi Nguyen's message of "Thu,  10 May 2018 20:50:50 +0200")

Thien-Thi Nguyen <ttn@gnu.org> writes:

> If you can structure whatever ‘catch’es the ‘throw’s to mutate
> state visible to CONDITION, then you can use ‘while CONDITION’.
> If that state is dynamic (e.g., declared w/ ‘defvar’), you can
> can reconfigure the ‘throw’ to simply mutate it directly, and
> eliminate the ‘catch’ part (and still use ‘while CONDITION’).

After thinking a bit about it, you're totally right, and it becomes much
simpler (read below).
>
> I suppose it's a matter of style.

Maybe not, maybe yours is indeed more efficient, since it amounts to
far fewer calls to accept-process-output.

> able to play multiple games simultaneously (i.e., run multiple
> independent child processes), and greedily spinning borks that.

Since from Emacs's perspective we're both blocking, you must mean that
you have less CPU available for the subprocesses, right?

> I'd appreciate seeing a skeleton of the code, because what i
> imagine it to be is probably not exactly what it is.  (I could
> be misunderstanding your description grossly.)

If you haven't yet connected the dots, this is for my new mode eglot.el
from the other thread.  Since it is very new, I think I'm just going to
apply your suggestion (diff below). It works fine and the code becomes
tighter, though it still doesn't solve the original problem that makes
the idle-timer not kick in in the meantime. (Later, I can explain more
about why I need that, and how I'm working around it).

diff --git a/eglot.el b/eglot.el
index aabaf54..d8fa8be 100644
--- a/eglot.el
+++ b/eglot.el
@@ -652,25 +652,20 @@ DEFERRED is passed to `eglot--async-request', which see."
   ;; bad idea, since that might lead to the request never having a
   ;; chance to run, because `eglot--ready-predicates'.
   (when deferred (eglot--signal-textDocument/didChange))
-  (let* ((done (make-symbol "eglot--request-catch-tag"))
-         (res
-          (catch done (eglot--async-request
-                       proc method params
-                       :success-fn (lambda (&rest args)
-                                     (throw done (if (vectorp (car args))
-                                                     (car args) args)))
-                       :error-fn (eglot--lambda
-                                     (&key code message &allow-other-keys)
-                                   (throw done
-                                          `(error ,(format "Oops: %s: %s"
-                                                           code message))))
-                       :timeout-fn (lambda ()
-                                     (throw done '(error "Timed out")))
-                       :deferred deferred)
-                 ;; now spin, baby!
-                 (while t (accept-process-output nil 0.01)))))
-    (when (and (listp res) (eq 'error (car res))) (eglot--error (cadr res)))
-    res))
+  (let (retval)
+    (eglot--async-request
+     proc method params
+     :success-fn (lambda (&rest args)
+                   (setq retval `(done ,(if (vectorp (car args))
+                                            (car args) args))))
+     :error-fn (eglot--lambda (&key code message &allow-other-keys)
+                 (setq retval `(error ,(format "Oops: %s: %s" code message))))
+     :timeout-fn (lambda ()
+                   (setq retval '(error "Timed out")))
+     :deferred deferred)
+    (while (not retval) (accept-process-output nil 30))
+    (when (eq 'error (car retval)) (eglot--error (cadr retval)))
+    (cadr retval)))
 
 (cl-defun eglot--notify (process method params)
   "Notify PROCESS of something, don't expect a reply.e"








  reply	other threads:[~2018-05-11 10:39 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-09 17:34 run-with-timer vs run-with-idle-timer João Távora
2018-05-09 18:10 ` Eli Zaretskii
2018-05-09 18:17 ` Eli Zaretskii
2018-05-09 18:40   ` João Távora
2018-05-09 18:59     ` Eli Zaretskii
2018-05-09 19:15       ` João Távora
2018-05-09 19:21         ` Eli Zaretskii
2018-05-09 19:34           ` João Távora
2018-05-09 20:00         ` Davis Herring
2018-05-09 20:18           ` João Távora
2018-05-10 11:46 ` Thien-Thi Nguyen
2018-05-10 12:28   ` João Távora
2018-05-10 18:50     ` Thien-Thi Nguyen
2018-05-11 10:39       ` João Távora [this message]
2018-05-11 11:05         ` João Távora
2018-05-12 17:57           ` Thien-Thi Nguyen
2018-05-12 17:37         ` Thien-Thi Nguyen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871seiqxwr.fsf@gmail.com \
    --to=joaotavora@gmail.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).