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

[-- Attachment #1: Type: text/plain, Size: 2793 bytes --]


() João Távora <joaotavora@gmail.com>
() Fri, 11 May 2018 11:39:16 +0100

   After thinking a bit about it, you're totally right, and it
   becomes much simpler (read below).

Cool, simpler (if it still works) is better.

   > I suppose it's a matter of style.

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

It's less efficient up until the point CONDITION is no longer
satisfied (since it has to compute/check CONDITION).  But past
that point, it's infinitely more efficient for the reason you
give.

   > 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 don't really know what i meant, actually.  I think it was just
my ego trying to sound bigger than my memory would permit.  You
will forgive the fool curmudgeon a lapse here and there, right?
It's been a long time since i used the verb "bork"... /pleading

The truth is that ‘gnugo--q’ is synchronous by design (it says
so right in the comment about ‘:srs’, after all -- but who reads
comments, anyway?!) and does indeed block (since 1st arg to
‘accept-process-output’ is specified) until input appears.

That said, top-level (user interaction) control only passes to
‘gnugo--q’ via ‘run-at-time’, which normally fires after two
seconds, plenty of time (even on this old computer) for Emacs to
move its pointers around.  Too, because the action is captured
in a timer object, Emacs has even more of a free hand to diddle
w/ its scheduling.  To sum up, spinning is what is going on,
true, but "greedily" maybe not so much.  Really, it's more like
bowing to the four corners of the earth (once) than spinning...

   > [...] seeing a skeleton of the code [...]

   If you haven't yet connected the dots, this is for my new
   mode eglot.el from the other thread.

Ah OK.  Sounds interesting!

   Since it is very new, I think I'm just going to apply your
   suggestion (diff below).

Cool.

   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).

OK.

-- 
Thien-Thi Nguyen -----------------------------------------------
 (defun responsep (query)
   (pcase (context query)
     (`(technical ,ml) (correctp ml))
     ...))                              748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

      parent reply	other threads:[~2018-05-12 17:37 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
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 [this message]

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=87in7s7p1y.fsf@gnuvola.org \
    --to=ttn@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=joaotavora@gmail.com \
    /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).