Re: Last change to process.c breaks fetching pop3 mail (gnus/pop3.el)

[Noah Friedman]

>The doc string for delete-process says:
>
>        Delete PROCESS: kill it and forget about it immediately.
>
>To me 'immediately' means that the value of delete-exited-processes
>does not apply here.  So I don't agree this is an error.

Ok.

>>   (2) network processes never have their sentinel called a final time
>
>Right, that's a real bug.
>
>The following patch should fix that (after undoing your change).
>
>*** process.c  24 May 2004 09:49:49 +0200      1.429
>--- process.c  31 May 2004 22:28:55 +0200
>***************
>*** 764,769 ****
>--- 764,770 ----
>      {
>        XPROCESS (process)->status = Fcons (Qexit, Fcons (make_number (0), 
> Qnil));
>        XSETINT (XPROCESS (process)->tick, ++process_tick);
>+       status_notify ();
>      }
>    else if (XINT (XPROCESS (process)->infd) >= 0)
>      {
>
>
>Unless you see problems with this, I'll install the patch tomorrow.

This was actually the first way I tried to do it, but something bothered me
about the fact that the sentinel for a network process can be called while
the buffer is still live; that's different than what happens for a
buffer with a child process and I was trying to maximize consistency.  

A program shouldn't have to know too much about how it's communicating with
another program, especially if it thinks it's communicating over a network.
For example ZenIRC has a hook to use an inferior program to make network
connections (e.g. for socks proxying) or to use open-network-stream
directly.  A sentinel still has to check for open/run or close/exit states,
but that's a trivial conditional whereas it's harder to work around the
case that sometimes a buffer still exists and sometimes it doesn't.

Why should that matter?  Well, a sentinel may attempt to reestablish a
connection if the remote end disconnected--in that case the buffer will
still exist.  But if the user kills the buffer, the client should not
attempt to reconnect to the remote server.  But if killing the buffer
invokes the sentinel before the buffer ceases to be active, how can it
tell which has happened?