Subject: Re: bug#22789: 25.1.50; In last master build https connections stop working

From: Eli Zaretskii <[email-masked]>
Date: Tue, 01 Mar 2016 19:00:23 +0200

> From: Alain Schneble <[email-masked]>
> CC: <[email-masked]>, <[email-masked]>, <[email-masked]>,
> 	<[email-masked]>
> Date: Tue, 1 Mar 2016 17:19:00 +0100
> 
> >> But we could probably make use of it and it would not require the timer
> >> at least for the async DNS resolution.  It would not solve the TLS issue
> >> though.  But maybe there is a similar notification for async sockets
> >> when they get connected?
> >
> > How do you envision we should make use of these notifications through
> > signals?  We try very hard not to do anything non-trivial in a signal
> > handler, except setting a flag that is then tested in due time.  If
> > that is what you had in mind, then you will face the same problems
> > with testing the flag as we face now: if the loop in
> > wait_reading_process_output is stuck in a call to 'pselect' with a
> > large timeout, Emacs might not be able to test the flag until the
> > timeout ends.
> 
> What you describe above is what I had thought of.  Regarding large
> timeout in pselect: isn't that what the sigmask to pselect is for?  To
> wait for a signal in addition to a file descriptor?  Or am I
> misunderstanding something?

No, it's me: I forgot that a signal will interrupt 'pselect', which
will return with EINTR, and that is already handled.

So yes, if we have a signal that is delivered from one of these
handshakes, it will cause the loop to run again.