bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin

[Ken Brown <kbrown@cornell.edu>]

On 6/18/2022 6:00 PM, Jim Porter wrote:
> On 6/18/2022 1:51 PM, Ken Brown wrote:
>> On 6/18/2022 3:02 PM, Jim Porter wrote:
>>> On 6/18/2022 10:52 AM, Ken Brown wrote:
>>>> No, I'm seeing the same results on Emacs 28.  On both Emacs 28 and Emacs 29, 
>>>> rev is apparently not seeing EOF unless echo outputs a newline, so rev keeps 
>>>> waiting for input.
>>>
>>> Ah ha! Thanks for debugging this. The minimal fix then would be to change the 
>>> command in em-extpipe-test-2 to either of these:
>>>
>>>    echo -N "bar" | rev *>temp
>>
>> This doesn't work.  It still hangs when run interactively...
> 
> Just to confirm, the above command hangs, but the following works, correct?
> 
>    echo -N "bar" | rev

Correct.

>>>    *echo "bar" | rev *>temp
>>
>> This works interactively...
> 
> All this makes me think that we could be dealing with a race condition in how 
> Eshell pipes I/O around. Maybe there's a timing issue in `eshell-close-target' 
> where we end up not sending EOF to the "rev" (or "sh") process?

I think I've just discovered an anomaly in "rev" on Cygwin that could partially 
explain what I'm seeing.  I'll investigate that before proceeding further.

> I'd be interested to see the results if you ran `M-x trace-function' for 
> `eshell-close-target' and `process-status' before trying these commands. 
> `process-status' should return `run' when called from inside 
> `eshell-close-target'. If it doesn't, then we'd neglect to send EOF to "rev" (or 
> "sh"), which would cause a hang like what you're seeing.
> 
> If that's not the issue, then I'm not sure what the issue would be exactly, but 
> poking around in `eshell-close-target', `eshell-insertion-filter', and 
> `eshell-sentinel' might yield some useful info.
> 
>> My guess is that it's the latter, but I don't know if it's worth pursuing this 
>> if Cygwin and EMBA are the only platforms on which there's a problem.  Of 
>> course, there might be other platforms and no one has reported it.
> 
> I think if we could figure out the real issue, it would be great to fix it. 
> Though if we can't, it would probably be ok to just fix the test by avoiding the 
> issue.