From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.bugs Subject: bug#24849: Is Emacs put in idle mode when window is not focused? Date: Tue, 1 Nov 2016 13:28:09 -0700 Message-ID: References: <83oa1znpah.fsf@gnu.org> <83wpgnm014.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1478032167 26603 195.159.176.226 (1 Nov 2016 20:29:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 1 Nov 2016 20:29:27 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 Cc: 24849@debbugs.gnu.org To: Johan Andersson , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 01 21:29:22 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 1c1fgD-0004jZ-B2 for geb-bug-gnu-emacs@m.gmane.org; Tue, 01 Nov 2016 21:29:09 +0100 Original-Received: from localhost ([::1]:51107 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1fgG-0000Tc-4N for geb-bug-gnu-emacs@m.gmane.org; Tue, 01 Nov 2016 16:29:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46215) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1fg9-0000TV-SF for bug-gnu-emacs@gnu.org; Tue, 01 Nov 2016 16:29:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c1fg6-0002XK-Nc for bug-gnu-emacs@gnu.org; Tue, 01 Nov 2016 16:29:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52259) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c1fg6-0002X2-Je for bug-gnu-emacs@gnu.org; Tue, 01 Nov 2016 16:29:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c1fg6-0004cS-CU for bug-gnu-emacs@gnu.org; Tue, 01 Nov 2016 16:29:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Nov 2016 20:29: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.147803210417707 (code B ref 24849); Tue, 01 Nov 2016 20:29:02 +0000 Original-Received: (at 24849) by debbugs.gnu.org; 1 Nov 2016 20:28:24 +0000 Original-Received: from localhost ([127.0.0.1]:39425 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c1ffM-0004bL-Mk for submit@debbugs.gnu.org; Tue, 01 Nov 2016 16:28:24 -0400 Original-Received: from dancol.org ([96.126.100.184]:43108) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c1ffK-0004bD-He for 24849@debbugs.gnu.org; Tue, 01 Nov 2016 16:28:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=oX/RfeQ+Qm1cfN0mVBeOhbl20nJeGb0w90IIE7cvxbQ=; b=Z6A07BZNt/FgL/G8eQd/0fPgjNxqvyI9dMrEtpUrxt2GBgqwn2+fMKUvHP4ZErW1w9pRRaPIc2sC13+BSR3jyMkQ6jt2g5N9GImUERNk5+8cNfK+RIDkqpz7+ZAc7EsOofRnktUUQq3G5UEhG47HJ302TE9Kzz7jHlgmDZV92UvqGgwBiBmjqKlhfhDYFOWciPi8/B9/m01MnYSVMs4JOjUbHl6pgr9KfSdBYG1IutyzvuVqvYi8i17x7uIscWkGP4zbx2+Dz7DrQ3MKWdQY6XUPL/cyMhEEwFZvIqvjPLu0Zm0AIKc9WQWdvUQ9RAoaZ4W3auC8ZJoDT5rGlL7yQQ==; Original-Received: from c-73-97-199-232.hsd1.wa.comcast.net ([73.97.199.232] helo=[192.168.1.173]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1c1ffI-0005kZ-U5; Tue, 01 Nov 2016 13:28:13 -0700 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:125238 Archived-At: 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