🚀 go-pugleaf

In emacs 18.57, running under BSD 4.3 on a VAX:

Symptom: Programs that use the function OPEN-NETWORK-STREAM will munch
CPU time if the network connection is closed unexpectedly.  For
example, if the user leaves an emacs running GNUS idle for a while and
the NNTP server times out the connection, emacs starts busy-waiting.

Explanation: File descriptors associated with network connection are
not being closed correctly in wait_reading_process_input().  As a
result, the select() in the main I/O loop wakes up immediately,
because these file descriptors are "readable" (that is, a read() call
would return zero, indicating end-of-file).

The guilty code starts on line 1751 of process.c:

    /* If we can detect process termination, don't consider the process
       gone just because its pipe is closed.  */
    #ifdef SIGCHLD
		  else if (nread == 0)
		    ;
    #endif

Obviously, a closed network connection is not going to raise SIGCHLD.

A minimal bugfix would be to change the statement on line 1754 to
read:

		  else if (nread == 0 && !NETCON_P (proc))

This would cause dead network connections to fall through to the code
which runs deactivate_process(), etcetera.


An observation: The code that handles network connections in process.c
seems to be in some kind of nether state.  In older versions of emacs
(eg, 18.54), network process objects had states like OPEN and CLOSED.
In emacs 18.57, network connections have states like RUN and EXIT.
The documentation of Fprocess_status() still mentions OPEN and CLOSED.
Symbols for OPEN and CLOSED states have been allocated in process.c,
but are not used.  It looks like whoever updated the process code to
use the new status mechanism didn't quite finish the job.  A coherent
set of patches to clean all this up would be nice, if somebody has the
time.

--Rob Austein