emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kim F. Storm
Subject: Re: Last change to process.c breaks fetching pop3 mail (gnus/pop3.el)
Date: 02 Jun 2004 15:51:29 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

Richard Stallman <address@hidden> writes:

>     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;
> 
> Do you mean "while the process is still live"?  It is normal to call
> the sentinel for a subprocess while its buffer is still live.
> But what does this have to do with the buffer, anyway?
> 
> We could eliminate the difference between network connections and
> subprocesses in this context by making Fdelete_process call
> Fkill_process for network connections too.  I am not sure whether that
> change is correct, but it sounds plausible.

I don't think that will work.

You cannot send a signal to a socket, so kill-process does not apply
to network processes.


IIUC, the problem is that a network process' sentinel would like to
be able to differentiate between the case where the connection is
closed because the remote end closed the connection, or because it
was closed by a call to delete-process.  

The wish is that the Lisp code does not have to treat using a network
process or a subprocess differently.

If remote closed the connection (or it was broken for other reasons)
we may want to reopen the connection in the sentinel.

If the connection was closed via an explicit call to delete-process, I
don't think the sentinel should ever try to reopen the connection!

Now, Noah says that delete-process may also be called via
kill_buffer_processes, but that only happens when we kill the process'
buffer, or when we exit emacs -- so in these cases, the sentinel should
not try to reconnect either.

So IMO, using delete-process should never cause the sentinel to try to
reopen the connection.  

The old code actually did accomplish just that -- but in a brutal way,
since the sentinel was not called after delete-process.


Now, to let the sentinel treat network processes and subprocesses
alike, Noah suggests that the sentinel could look to see if the
process' buffer is still alive.  But that breaks for network
processes.  

I think looking at the buffer is the wrong approach -- the sentinel
must look at the "status" message that it receives (see below).

With my proposed change (just call status_notify in Fdelete_process)
does indeed allow the sentinel to differentiate between a connection
closed via delete-process and by remote (or a broken connection):

The string passed to the sentinel is "finished\n" if delete-process
was called;  otherwise it is "exited abnormally with code 256".

Of course, that may be different from what is returned from a
subprocess, but the amount of Lisp code needed to treat the extra case
is minimal, so what else is needed ?

I will undo Noah's change and install my patch shortly.

-- 
Kim F. Storm <address@hidden> http://www.cua.dk





reply via email to

[Prev in Thread] Current Thread [Next in Thread]