False start and early start are not multi-thread recv/send safe
An application that is sending and receiving from different threads after handshake is complete cannot take advantage of false start. We should consider making this a supported case to ease the use of gnutls in multi-threaded applications.
Original report: This is https://bugs.debian.org/922879 submitted by Rémi Denis-Courmont, I am as acting as proxy for Rémi:
With GnuTLS 3.6.x, VLC pseudo-randomly fails to connect to HTTP/2 servers due to what seems like a race condition in GnuTLS. See also https://trac.videolan.org/vlc/ticket/21951 .
To reproduce, run VLC a dozen time or so (depending on the system), until hitting a failure:
# vlc -Irc https://streams.videolan.org/issues/21941/Greatest%20Motown%20Songs%2060s%2070s%20Hits.mp3
(Ctrl+C to abort if it does not fail straight away)
The problem appears to be caused by the "fix" for Debian bug 849807 / #158 (closed) which does not seem to follow the GnuTLS thread safety rules.
Since breaking working applications seems far worse than protecting broken applications from shooting themselves in the foot, I suggest reverting 849807 (i.e. GnuTLS commit 6a62ddfc ).