Ian (CCed): I've run into an issue where `accept-process-output' is always waiting an extra 10ms (READ_OUTPUT_DELAY_INCREMENT) after receiving output as long as the PROCESS passed to it is nil. This appears to be related to the change you made in bug#20978 and I'm wondering if you can shed more light on when `accept-process-output' should wait for more input. Eli Zaretskii writes: >> From: Steven Allen >> Cc: rpluim@gmail.com, 78773@debbugs.gnu.org, larsi@gnus.org >> Date: Sat, 14 Jun 2025 09:15:00 -0700 >> >> Eli Zaretskii writes: >> >> > We wait the second time because there could be more input, so I don't >> > see how this could be wrong in general. I also don't quite see the >> > "gotcha!" in your analysis below: >> >> There is no available input. There might be more input in 10ms > > That's what I meant by "there could be more input". I'd rather make use of what we know: we don't know if we'll get more data in the near future but we *do* know that we've just received some data that the caller (of `accept-process-output`) may want to handle. So we might as well return to the caller and give them a chance to do something about it. The exception to this rule is adaptive read buffering where explicitly _don't_ want to yield too little data at a time if we expect we'll receive more in the near future. I agree we should wait a bit longer in that case (the attached patch should handle that). >> My understanding is that `accept-process-output' is supposed to return >> immediately when output has been read BOTH when PROCESS is nil and when >> it is non-nil. > > That's true, but wait_reading_process_output is called not just by > accept-process-output, it is called by several other callers, and in > that case it is not necessarily true that we need to exit immediately > upon the first available channel. Keep in mind that reading from a > subprocess also invokes a filter function, if there is one, so it > might make sense in some cases to read from more than one source, > perhaps even from all of the ones that have output ready to be read. > >> Looking at the history, it looks like the code in question was changed >> in bug#20978. However, from what I can tell, we should only apply >> adaptive read buffering when `process-adaptive-read-buffering' is >> non-nil. I think we may need to change the check in question to: >> >> if (!process_output_skip && (!wait_proc || wait_proc == XPROCESS (proc))) >> wait = MINIMUM; > > That could indeed fly, but process-adaptive-read-buffering is non-nil > by default. Does url set it to nil? It is nil by default as of bug#75574 (8a669b6be523e043423b81571a8c94cb49ccc8e5). > In any case, I think the addition of process-adaptive-read-buffering > test should only affect the case when wait_proc is zero. Looking at this more, I'm becoming more and more convinced that this was a bug inadvertently introduced by 12a2691fb254db20607b2067a12b795a6d7c6649. That patch was trying to make adaptive read buffering work again but it went too far and applied the delay everywhere. I've attached what I think is the correct patch, but I've also CCed Ian (author of #20978 and the associated patch) in hopes of getting a bit more context here.