[Bug: 21.4.18] startls gets stuck

[stephen at xemacs.org]

Simon Josefsson writes:

 > Did you see the backtrace?  smtpmail.el blocked XEmacs, and C-g
 > generated a backtrace:

Yes.  As you say, smtpmail.el blocked XEmacs.  It's your process, not
ours.  That doesn't mean it's not our bug, but it does mean that
you're in a better position than I am to diagnose it.

 > I think XEmacs should return from accept-process-output if the server
 > has closed the connection (I believe that is what happened), instead
 > of waiting for more input that will never arrive.

But if the process is still running you have a deadlock.  I'll take a
look at accept-process-output and see if maybe Google's timing is
creating a race condition where the process is still alive, so the
function is entered, but then the process dies and XEmacs doesn't
notice.  That would be an XEmacs bug, of course.

Nonetheless, the possibility for a non-buggy deadlock is quite real,
as many large ISPs do very bizarre things with their MTAs.

 > 	(while (not (search-forward "\r\n" nil t))
 > 	  (unless (memq (process-status process) '(open run))
 > 	    (throw 'done nil))
 > 	  (accept-process-output process)
 > 	  (goto-char smtpmail-read-point))

I really think you should put a timeout on accept-process-output,
regardless of whether an XEmacs bug is involved in the current issue.