From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Johan Andersson Newsgroups: gmane.emacs.bugs Subject: bug#24849: Is Emacs put in idle mode when window is not focused? Date: Tue, 1 Nov 2016 21:33:59 +0100 Message-ID: References: <83oa1znpah.fsf@gnu.org> <83wpgnm014.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c063bdcbf1aa40540433f7e X-Trace: blaine.gmane.org 1478032549 32488 195.159.176.226 (1 Nov 2016 20:35:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 1 Nov 2016 20:35:49 +0000 (UTC) Cc: 24849@debbugs.gnu.org To: Daniel Colascione Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 01 21:35:44 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1c1fm6-0004Sp-FH for geb-bug-gnu-emacs@m.gmane.org; Tue, 01 Nov 2016 21:35:14 +0100 Original-Received: from localhost ([::1]:51121 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1fm9-00012H-8x for geb-bug-gnu-emacs@m.gmane.org; Tue, 01 Nov 2016 16:35:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47397) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1flx-0000z1-UU for bug-gnu-emacs@gnu.org; Tue, 01 Nov 2016 16:35:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c1flu-0006o6-Om for bug-gnu-emacs@gnu.org; Tue, 01 Nov 2016 16:35:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52264) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c1flu-0006nn-L8 for bug-gnu-emacs@gnu.org; Tue, 01 Nov 2016 16:35:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c1flu-0004m7-AG for bug-gnu-emacs@gnu.org; Tue, 01 Nov 2016 16:35:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Johan Andersson Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Nov 2016 20:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24849 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 24849-submit@debbugs.gnu.org id=B24849.147803247518321 (code B ref 24849); Tue, 01 Nov 2016 20:35:02 +0000 Original-Received: (at 24849) by debbugs.gnu.org; 1 Nov 2016 20:34:35 +0000 Original-Received: from localhost ([127.0.0.1]:39430 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c1flL-0004lH-Rf for submit@debbugs.gnu.org; Tue, 01 Nov 2016 16:34:35 -0400 Original-Received: from mail-qk0-f180.google.com ([209.85.220.180]:35062) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c1flJ-0004l4-Ky for 24849@debbugs.gnu.org; Tue, 01 Nov 2016 16:34:26 -0400 Original-Received: by mail-qk0-f180.google.com with SMTP id z190so212863674qkc.2 for <24849@debbugs.gnu.org>; Tue, 01 Nov 2016 13:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=burtcorp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MOSzvzCA7zeogJaK0ddmCgnpmLV4QnW79RbVdOmrdT0=; b=EvNbu1K6IldeW312e1XDFa0Cwls16lkZCcf+ITu2MVFifXbBTsl1yBvF/Gl30ExbBa br/pwgemRJkcPFxsWhaxbWOpQPU55PAt/wKYs/gm2t7dQCuTnNZ0+UTasHEvE1We14fR q0j+wPsjZ8NoP6/VcK24bhmk2pev+GM1Gnas9O0M9Jv08GEIs1qKefu/MaM9XPBGuLpd 47sd0UC6NjdxwFORB8rLFUn2GzwMvJX/1KGNc9+CY5dtrs7t5pXtxqsK/kJLavWIFsEl qH2ZvdXO8cuLlTDBZRo77CvDHirw/glbxC2iN33D3YUsM6nzcfMITzrqiPlCfGmDGe1c PWJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MOSzvzCA7zeogJaK0ddmCgnpmLV4QnW79RbVdOmrdT0=; b=azrbqRRrKt3R8AKs5/lpACkvq5pYDERmp3L8W+koHwm73XhTf/6gjhQ7vek7hJezXP +XQ0LuBhEqXjZVGhVPbLD0CHCYhwjMk5SLvWmVtK5iZOM931pfwtSbypLJ5CEl46PdNn m6Ls1OnuwdOlsyNecMqj2CsAG2kYWbNe7gOeTImVZTpdwwxQotPHdmIoLX3X7wfbCALP Jn7M/4WzM6M9Z1NqSWTVeG272mzmvAG3E0LLuAaer+E6biuCfsEy5WyBnlvVuvHR7d/n WSou39zICIXJ8KFAlET9GgS+kjl7uoSeNL4ZeWDUdhQdfsK08q1Qyie9luj6p2e3NVQb Z76A== X-Gm-Message-State: ABUngvf3iWfeU1tE03jdg1mfxwUn2WyOKzJX+wcMFie3B6SrAMx1i9CzhsizNrMm0tQfdPkoXHhg3QfPGKN1jA== X-Received: by 10.55.123.133 with SMTP id w127mr224207qkc.298.1478032460014; Tue, 01 Nov 2016 13:34:20 -0700 (PDT) Original-Received: by 10.237.38.33 with HTTP; Tue, 1 Nov 2016 13:33:59 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:125239 Archived-At: --94eb2c063bdcbf1aa40540433f7e Content-Type: text/plain; charset=UTF-8 > BTW: please don't top-post Sorry, what? > Are you sure that your subprocess isn't buffering its output? No. Does that make a difference? > Can you catch Emacs in the act? What do you mean? > Assuming GNU/Linux here. On a Mac here, but I might be able to find a GNU/Linux machine at work tomo. On Tue, Nov 1, 2016 at 9:28 PM, Daniel Colascione wrote: > BTW: please don't top-post > > On 11/01/2016 01:18 PM, Johan Andersson wrote: > >> I added the set-process-filter in case that would make a difference, but >> I don't think that is the issue here. The issue is that the services >> (sub processes of Emacs as you say) takes a long time to respond when >> Emacs is idle. If I run the same command from a terminal, that doesn't >> happen. >> > > Are you sure that your subprocess isn't buffering its output? > > Can you catch Emacs in the act? > > (Assuming GNU/Linux here.) Run emacs with "strace -s256 -o trace -ff -tt > emacs" and look at the trace.* files produced. You should have one for each > thread in each process. You should be able to identify the process involved > from the system calls in each. (Look for execve.) Now, look for the > write(2) system call from your subprocess and see how much time passes > between that system call and Emacs waking up from pselect. > > If Emacs wakes up very soon after that write(2), the problem lies in your > code. If there is a big delay between that write(2) and Emacs returning > from pselect, the problem is likely in Emacs. > > >> On Tue, Nov 1, 2016 at 9:13 PM, Eli Zaretskii > > wrote: >> >> > From: Johan Andersson > > >> > Date: Tue, 1 Nov 2016 20:48:59 +0100 >> > Cc: 24849@debbugs.gnu.org >> > >> > (let* ((default-directory "/tmp") >> > (process (start-process "server" nil "python" "-m" >> "SimpleHTTPServer" "8000"))) >> > (set-process-filter >> > process >> > (lambda (_ output) >> > ;; ... >> > ))) >> > >> > What happens in practice is that, when I get to work, I select the >> services I need and start them (unless >> > Emacs was killed, they are already started). Sometimes I use Emacs >> quite frequently and then this is not so >> > much of an issue because Emacs does not have time to idle. But when >> I don't use Emacs for a while, it will >> > hang waiting for the response from the service (because Emacs is >> idle). >> >> So you are saying that the service, which is a sub-process of Emacs, >> produces some output, but Emacs doesn't read that output timely enough >> because it's idle? That's not possible, I think: when Emacs is idle, >> it is most of the time stuck inside a call to 'pselect', which should >> return immediately when some input arrived from a sub-process. >> >> So I guess I still don't understand something in your setup. But >> what? >> >> >> >> >> -- >> Johan Andersson >> System Developer, Burt >> www.burtcorp.com >> Cell: +46 761 041607 >> https:// github.com/rejeep >> | http://twitter.com/rejeep | >> http://twitter.com/burtcorp >> > -- Johan Andersson System Developer, Burt www.burtcorp.com Cell: +46 761 041607 https:// github.com/rejeep | http://twitter.com/rejeep | http://twitter.com/burtcorp --94eb2c063bdcbf1aa40540433f7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> BTW: please don'= t top-post
<= br>
So= rry, what?

> Are you sure that your subproce= ss isn't buffering its output?

No. Does= that make a difference?

> Can you catch Emacs in the= act?

What do = you mean?

> Assuming GNU/Linux here.

On a Mac here, but I might be able to find a GNU/Linux machine at work to= mo.

On Tue, Nov 1, 2016 at 9:28 PM, Daniel Colascione &l= t;dancol@dancol.org<= /a>> wrote:
BTW: please don'= ;t top-post

On 11/01/2016 01:18 PM, Johan Andersson wrote:
I added the set-process-filter in case that would make a difference, but I don't think that is the issue here. The issue is that the services (sub processes of Emacs as you say) takes a long time to respond when
Emacs is idle. If I run the same command from a terminal, that doesn't<= br> happen.

 Are you sure that your subprocess isn't buffering its output?

Can you catch Emacs in the act?

(Assuming GNU/Linux here.) Run emacs with "strace -s256 -o trace -ff -= tt emacs" and look at the trace.* files produced. You should have one = for each thread in each process. You should be able to identify the process= involved from the system calls in each. (Look for execve.) Now, look for t= he write(2) system call from your subprocess and see how much time passes b= etween that system call and Emacs waking up from pselect.

If Emacs wakes up very soon after that write(2), the problem lies in your c= ode. If there is a big delay between that write(2) and Emacs returning from= pselect, the problem is likely in Emacs.


On Tue, Nov 1, 2016 at 9:13 PM, Eli Zaretskii <eliz@gnu.org
<mailto:eliz@gnu.org>> wrote:

=C2=A0 =C2=A0 > From: Johan Andersson <johan.andersson@burtcorp.com
=C2=A0 =C2=A0 <mailto:johan.andersson@burtcorp.com>>
=C2=A0 =C2=A0 > Date: Tue, 1 Nov 2016 20:48:59 +0100
 =C2=A0 =C2=A0 > Cc: 24849@debbugs.gnu.org <mailto:24849@debbugs.gnu.org><= br> =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > (let* ((default-directory "/tmp")
=C2=A0 =C2=A0 > (process (start-process "server" nil "pyt= hon" "-m" "SimpleHTTPServer" "8000"))) =C2=A0 =C2=A0 > (set-process-filter
=C2=A0 =C2=A0 > process
=C2=A0 =C2=A0 > (lambda (_ output)
=C2=A0 =C2=A0 > ;; ...
=C2=A0 =C2=A0 > )))
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > What happens in practice is that, when I get to work, I = select the services I need and start them (unless
=C2=A0 =C2=A0 > Emacs was killed, they are already started). Sometimes I= use Emacs quite frequently and then this is not so
=C2=A0 =C2=A0 > much of an issue because Emacs does not have time to idl= e. But when I don't use Emacs for a while, it will
=C2=A0 =C2=A0 > hang waiting for the response from the service (because = Emacs is idle).

=C2=A0 =C2=A0 So you are saying that the service, which is a sub-process of= Emacs,
=C2=A0 =C2=A0 produces some output, but Emacs doesn't read that output = timely enough
=C2=A0 =C2=A0 because it's idle?=C2=A0 That's not possible, I think= : when Emacs is idle,
=C2=A0 =C2=A0 it is most of the time stuck inside a call to 'pselect= 9;, which should
=C2=A0 =C2=A0 return immediately when some input arrived from a sub-process= .

=C2=A0 =C2=A0 So I guess I still don't understand something in your set= up.=C2=A0 But
=C2=A0 =C2=A0 what?




--
Johan Andersson
System Developer, Burt
www.burtcorp.com <http://www.burtcorp.com>
Cell: +46 761 041607
https:// <http://twitter.com/rejeep>github.com/rejeep
<http://github.com/rejeep> | http://twitter.com/rejeep |
http://twitter.com/burtcorp



--
Johan Andersson
System Developer, Burt
=
Cell: +46 761 041607
--94eb2c063bdcbf1aa40540433f7e--