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

[Alain Schneble]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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
>> 
>> 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?

>> 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.

That sounds like a better idea than having a separate timer...