bug-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: Eli Zaretskii
Subject: bug#22789: 25.1.50; In last master build https connections stop working
Date: Tue, 01 Mar 2016 19:00:23 +0200

> From: Alain Schneble <a.s@realize.ch>
> CC: <schwab@suse.de>, <larsi@gnus.org>, <j_l_domenech@yahoo.com>,
>       <22789@debbugs.gnu.org>
> 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.





reply via email to

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