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

[Eli Zaretskii]

> From: Alain Schneble <a.s@realize.ch>
> Date: Tue, 1 Mar 2016 15:25:53 +0100
> Cc: Andreas Schwab <schwab@suse.de>, j_l_domenech@yahoo.com,
>       22789@debbugs.gnu.org
> 
> > Andreas Schwab <schwab@suse.de> writes:
> >
> >> Lars Ingebrigtsen <larsi@gnus.org> writes:
> >>
> >>> And I would guess that the same is true for the async DNS resolution --
> >>> those processes also need some progress, probably?  
> >>
> >> getaddrinfo_a provides async notification (SIGEV_SIGNAL).
> >
> > But we're not using that.
> >
> > Anyway, all this async DNS/TLS stuff can probably be taken out of
> > wait_reading_process_output completely, and just be run from the
> > proposed new timer thing...  That'll be cleaner, too.
> 
> 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.

> If there exists an approach that does not require timers, then I
> guess this would be the preferred one...

I think I suggested one such way.  In a nutshell, it does the same to
the loop as a timer would, but without actually running a timer.