Hi Lukas,
On Tue, Jan 28, 2014 at 08:24:39PM +0100, Lukas Tribus wrote:
> Hey guys,
>
>
> >> Do you still want me to bisect? Or should I wait? If you think the
> >> problem is the same I'll just test the fix :-)
> >
> > Don't waste your time bisecting. I'll propose you to test the patch
> > instead. The problem I've seen is always the same and is related to
> > the fact that the SSL layer might have read all pending data from a
> > socket but not delivered everything to the buffer by lack of space
> > for example. Once the buffer is flushed and we want to read what
> > follows, we re-enable polling. But there's no more data pending so
> > poll() does not wake up the reader anymore. It happened to work due
> > to the speculative polling we've been using a lot, but sometimes it
> > was not intentional and caused some syscalls to be attempted for no
> > reason (resulting in many EAGAIN in recvfrom). When fixing this, we
> > also break what made SSL happen to work :-(
> >
> > I've been wanting for about 1 year to change the polling to include
> > the status of the FD there (EAGAIN or not). But since it's complex
> > and there were not many reasons for doing it, I preferred to delay.
> > Now is a good opportunity given that I broke it several times in the
> > last few weeks.
>
> For the record:
>
> Has this been fixed by commit 4afd70aea ("BUG/MAJOR: fix freezes during
> compression") or is that a unrelated problem?
Oh yes, sorry for not being clear on this. I wanted to send an e-mail to
the list after pushing all the fixes and forgot after I fell asleep :-/
So in practice, I have performed the required polling changes which were
responsible for several of the recent regressions everytime I touched
areas close to ev_*poll, connection.h or to ssl_sock.c. And thanks to
Sander's help, I found that one of the recent change consisting in
having this new CF_WAKE_WRITE flag mentionned by tasks who must sleep
because they cannot write was incomplete as it did not correctly cover
the case that (too rarely) happens for compressed data if the buffer
is not empty and some non-compressible data do not fit.
Thus yes, all these bugs were fixed. I'll send a status update in
another e-mail so that nobody misses it.
Best regards,
Willy
