The test case from below hangs when executed with emacs -Q --batch -l apo-tests.el -f ert-run-tests-batch-and-exit It's not 100% reproducible, but it seems to hang 80% of the time. The test is fairly complicated and involves a TLS connection, a sub-process and a background thread. The background thread starts a sub-process and reads all its output until the process terminates. Then the main thread opens a TLS connection, sends a HTTP request and tries to read the response. At this point, accept-process-output hangs even though there is output available. I think the reason for this problem is that the sub-process uses a file descriptor (usually number 6) and sets fd_callback_info[6].waiting_thread to the background thread (in compute_non_keyboard_wait_mask) . Later, the TLS connection receives a file descriptor with the same number (6) because the sub-process closed it already. That would be fine, however fd_callback_info[6].waiting_thread is still set to the background thread. So this time compute_non_keyboard_wait_mask doesn't include 6 in the wait mask. Because 6 is not in the wait mask, emacs_gnutls_record_check_pending will not be called and Emacs doesn't notice the buffered output. The intention in the code seems to be that clear_waiting_thread_info resets fd_callback_info[6].waiting_thread to NULL, however by the time that clear_waiting_thread_info is called, max_desc was reduced to 4, because somebody closed file descriptors 5 and 6. So clear_waiting_thread_info doesn't touch fd_callback_info[6]. A possible solution would be to reset the .waiting_thread field in delete_read_fd, like so: diff --git a/src/process.c b/src/process.c index 08cb810ec13..74d0bf252ab 100644 --- a/src/process.c +++ b/src/process.c @@ -513,6 +513,9 @@ delete_read_fd (int fd) { fd_callback_info[fd].func = 0; fd_callback_info[fd].data = 0; + + if (fd_callback_info[fd].waiting_thread == current_thread) + fd_callback_info[fd].waiting_thread = NULL; } } With this change, the test doesn't hang. Helmut