From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: A question regarding sit-for (and while-no-input) Date: Thu, 06 Sep 2018 12:59:00 +0100 Message-ID: <87ftymzvjv.fsf@gmail.com> References: <87k1nyzwx5.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1536235034 12561 195.159.176.226 (6 Sep 2018 11:57:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 6 Sep 2018 11:57:14 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 06 13:57:10 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fxsuL-000397-Hu for ged-emacs-devel@m.gmane.org; Thu, 06 Sep 2018 13:57:09 +0200 Original-Received: from localhost ([::1]:60956 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fxswR-00022e-W3 for ged-emacs-devel@m.gmane.org; Thu, 06 Sep 2018 07:59:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37029) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fxswL-00022Y-Ja for emacs-devel@gnu.org; Thu, 06 Sep 2018 07:59:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fxswD-0002q7-R6 for emacs-devel@gnu.org; Thu, 06 Sep 2018 07:59:09 -0400 Original-Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]:34611) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fxswD-0002cz-1V for emacs-devel@gnu.org; Thu, 06 Sep 2018 07:59:05 -0400 Original-Received: by mail-wr1-x434.google.com with SMTP id g33-v6so11122436wrd.1 for ; Thu, 06 Sep 2018 04:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:references:date:in-reply-to:message-id:user-agent :mime-version:content-transfer-encoding; bh=3B+q0DIg3bTx2aDXen7deG9WRqHHLjvcr0WOZdMMHJo=; b=NHXaZ8CyStnMkpPUSnhGdoGT54FdIjmqtc34L0Ho+cgAUsPwBK/OZ7VQAspLMTcanb sl9ibMOcRSDLXXogOc1eg6oAdtEA8d+42RLviq+BiQS4IHWssl3aZrO9oFCBS6C0hEtT JiDeJe5Pgj8/ddVK4RYgpVrzVEKKPlwZyLxJk1G6YSmsiGFZ7CvN34oEmayyZzGqCznG LgbGpGfiGCCN6+DJXDfxq9wkRgJSV62zELXY0M3xiEQZhxNmlRYHPiiZtfFiFqBo17vG /8S6oad0Z33s/KTpMB1ORpTjnKbmuS2jWbYXXZOO8a6zce3T9pih7T9BFb3iMHsezIgV arsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=3B+q0DIg3bTx2aDXen7deG9WRqHHLjvcr0WOZdMMHJo=; b=N6c1B+YaF85qmYVmg2JUV2LiHmaWACdlTVSpBfCFzphu7Gja7GM6MTPauYyhVY9mN+ sJ1UvFUcBQvjr8gNZPe/83bour1skdgkuoYfhs/iEUoMXOvU7am9xgcZ6BPVGJBjqbsS bTaEMqZTCH06w0LgzasKzlxnTeQIy5GVIDE04k3tH8NNfplTBOs1xIrOi/tcKkNBGC3r oDsOaok/dw0UBHUpoECOoROEkAQL/u77WPYeRHFr4K6MOTY7EMp1wWfRu4vDC33Vn8+N osZX6LSxHPa1a8ujn5RMVwks9hY209DMe8WBtfFJJ/1/yabFJCtuHfGBDNXpCeO0Y6vB R98A== X-Gm-Message-State: APzg51BTswihr8bu5xoJfxjAG//XA4LeU32+6hFL2vVvxQsnd0zmRbqi r81zVKOedrhLc1/Za4bhKHqDqJoH X-Google-Smtp-Source: ANB0VdaOlts7mybdUdlDSTuFcuQbAPBITNQq63AQRdeLA6lLWjlu48VfuYV5NA8uYFlke1dLKxWCAg== X-Received: by 2002:a5d:428a:: with SMTP id k10-v6mr2159596wrq.225.1536235143503; Thu, 06 Sep 2018 04:59:03 -0700 (PDT) Original-Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id k34-v6sm6865802wre.18.2018.09.06.04.59.01 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 06 Sep 2018 04:59:02 -0700 (PDT) In-Reply-To: <87k1nyzwx5.fsf@gmail.com> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vor?= =?utf-8?Q?a=22's?= message of "Thu, 06 Sep 2018 12:29:26 +0100") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::434 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:229337 Archived-At: Jo=C3=A3o T=C3=A1vora 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=C3=A3o 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 =3D "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=C3=A3o