GNU bug report logs - #32986
27.0.50; unexpected delay in while-no-input + accept-process-output

Previous Next

Full log

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

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 32986 <at> debbugs.gnu.org
Subject: Re: bug#32986: 27.0.50;
 unexpected delay in while-no-input + accept-process-output
Date: Sun, 14 Oct 2018 23:08:30 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: João Távora <joaotavora <at> gmail.com>
>> Date: Tue, 9 Oct 2018 09:47:58 +0100
>> Cc: 32986 <at> debbugs.gnu.org
>> 
>> A final question: process input is also considered during the
>> sit-for, meaning a filter can throw to an
>> enclosing tag and end it prematurely and immediately, right?
>
> You mean, if the only input is from a subprocess?  No, I don't think
> so.  Do you have evidence to the contrary?

Hi Eli,

Sorry for the delay in my reply.

I meant the following, which appears to do what I want in my testing:

   (joaot/time
    (catch 'done
      (progn (make-process :name "test"
                           :filter (lambda (proc string)
                                     (message "Hey %s just got %s" proc string)
                                     (throw 'done nil))
                           :command '("sh" "-c" "sleep 2 && echo bla"))
             (while (sit-for 30))))) ; Took 02.011 seconds and returned nil

The above result is with C-u C-x C-e and no further keyboard input. If
however I press C-u C-x C-e SPC as in my previous experiments, I get the
expected very small delay.

In other words, subprocess input is considered during a 'sit-for'. It
doesn't end it, but that's OK if catch/throw is used.

I'd just like to confirm that I'm not dealing with an "dirty room"
situation here, to use your metaphor.

João

Previous Next

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