GNU bug report logs - #24849
Is Emacs put in idle mode when window is not focused?

Previous Next

Package: emacs;

Reported by: Johan Andersson <johan.andersson <at> burtcorp.com>

Date: Tue, 1 Nov 2016 15:37:02 UTC

Severity: normal

Tags: confirmed

Merged with 22993, 41865

Found in version 25.0.92

Full log


Message #23 received at 24849 <at> debbugs.gnu.org (full text, mbox):

From: Johan Andersson <johan.andersson <at> burtcorp.com>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 24849 <at> debbugs.gnu.org
Subject: Re: bug#24849: Is Emacs put in idle mode when window is not focused?
Date: Tue, 1 Nov 2016 21:33:59 +0100
[Message part 1 (text/plain, inline)]
> 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 <dancol <at> dancol.org> 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 <eliz <at> gnu.org
>> <mailto:eliz <at> gnu.org>> wrote:
>>
>>     > From: Johan Andersson <johan.andersson <at> burtcorp.com
>>     <mailto:johan.andersson <at> burtcorp.com>>
>>     > Date: Tue, 1 Nov 2016 20:48:59 +0100
>>     > Cc: 24849 <at> debbugs.gnu.org <mailto:24849 <at> 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 <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
www.burtcorp.com
Cell: +46 761 041607
https:// <http://twitter.com/rejeep>github.com/rejeep |
http://twitter.com/rejeep | http://twitter.com/burtcorp
[Message part 2 (text/html, inline)]

This bug report was last modified 3 years and 287 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.