Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[Robert Pluim]

Dmitry Gutov <address@hidden> writes:

> On 3/13/18 5:46 PM, Robert Pluim wrote:
>
>> It got caught before it got committed, so not that bad.
>
> I mean the general possibility of having somebody who comes later
> reverse the fix.
>
> For some code the odds of this happening are fairly small (via
> architectural decisions, or segregating a fix into a separate unit of
> code, or maybe just commenting profusely). Not so in this case,
> apparently.

As Eli has pointed out, it's a very fiddly area to work in.

>>> Fiddly, hard-to-reproduce misbehavior is the ideal target for
>>> regression tests, IMO.
>>
>> My current test-case for 21337 is 'visit a bunch of files, make sure
>> global-auto-revert is turned on and auto-revert-use-notify is t, run
>> Gnus (or anything else that makes TLS connections), wait for errors to
>> be signalled by inotify'. I don't know how to write a regression test
>> for that.
>
> Maybe there's a way to simulate the critical conditions more directly?

It has to involve TLS and reading from TLS connections. I don't think
we want emacs' regression tests to be making connections to servers on
the internet. I've never tried to use 'make-network-process' to create
a TLS server in emacs, but perhaps that could be used instead.

Robert