bug#33018: 26.1.50; thread starvation with async processes and accept-process-output

[Basil L. Contovounesios]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Basil L. Contovounesios" <contovob@tcd.ie>
>> Cc: <michael.albinus@gmx.de>,  <33018@debbugs.gnu.org>
>> Date: Wed, 17 Oct 2018 18:37:00 +0100
>> 
>> #0  0x00007ffff766a2a4 in __GI___libc_write (fd=1, buf=0x5555559c1b30, 
>> nbytes=4096)
>>     at ../sysdeps/unix/sysv/linux/write.c:27
>> #1  0x00007ffff75fb56d in _IO_new_file_write (f=0x7ffff7739760 
>> <_IO_2_1_stdout_>, 
>>     data=0x5555559c1b30, n=4096) at fileops.c:1203
>> #2  0x00007ffff75fa88f in new_do_write (fp=0x7ffff7739760 <_IO_2_1_stdout_>, 
>>     data=0x5555559c1b30 "pan></span></h2>\n<p>Emacs is primarily a <a
>> href=\"/wiki/Text_editor\" title=\"Text editor\">text editor</a> and is
>> designed for manipulating pieces of text, although it is capable of 
>> formatting
>> and print"..., to_do=to_do@entry=4096) at fileops.c:457
>> #3  0x00007ffff75fc6f9 in _IO_new_do_write (fp=<optimized out>, 
>> data=<optimized out>, 
>>     to_do=4096) at fileops.c:433
>> #4  0x00007ffff75fa6d8 in _IO_new_file_sync (fp=0x7ffff7739760 
>> <_IO_2_1_stdout_>)
>>     at fileops.c:813
>> #5 0x00007ffff75ef6ed in __GI__IO_fflush (fp=0x7ffff7739760 
>> <_IO_2_1_stdout_>)
>> at iofflush.c:40
>> #6  0x00005555555918bb in write_data (out=0x7ffff7739760 <_IO_2_1_stdout_>, 
>> out2=0x0, 
>>     buf=0x5555559a9590 "pan></span></h2>\n<p>Emacs is primarily a <a
>> href=\"/wiki/Text_editor\" title=\"Text editor\">text editor</a> and is
>> designed for manipulating pieces of text, although it is capable of 
>> formatting
>> and print"..., bufsize=4096, skip=0x7fffffffd0e8,
>>     written=0x7fffffffd0e0) at retr.c:207
>> #7  0x000055555559204f in fd_read_body (downloaded_filename=0x5555555e18a0 
>> "-", fd=4, 
>>     out=0x7ffff7739760 <_IO_2_1_stdout_>, toread=198224, startpos=0, 
>> qtyread=0x7fffffffda20, 
>>     qtywritten=0x7fffffffd9d0, elapsed=0x7fffffffda28, flags=1, out2=0x0) at 
>> retr.c:498
>
> Looks like the buffer of the pipe through which Emacs reads the stuff
> is full, and wget waits for some space there?

Would that imply that different threads/processes are (re)using the same
buffer/pipe?

FWIW, strace -p <pip of stuck emacs> gives:

pselect6(14, [6 7], [], NULL, {tv_sec=99975, tv_nsec=320947003}, {NULL, 8}

and strace -p <pip of stuck wget> gives:

write(1, ">]</span></span></h2>\n<p>Emacs i"..., 4096

The former reminded me of bug#24201: https://debbugs.gnu.org/24201

-- 
Basil