[gnutls-devel] GnuTLS | WIP: fixed operation under multiple threads (!935)

[Development of GNU's TLS library]

Hugo Beauzée-Luyssen started a new discussion on lib/record.c:

>  		 * data. We allow sending however, if we are in false start handshake
>  		 * state. */
>  		if (session->internals.recv_state != RECV_STATE_FALSE_START &&
> +		    session->internals.recv_state != RECV_STATE_FALSE_START_HANDLING &&
>  		    session->internals.recv_state != RECV_STATE_EARLY_START &&
> -		    !(session->internals.hsk_flags & HSK_EARLY_DATA_IN_FLIGHT))
> -			return gnutls_assert_val(GNUTLS_E_UNAVAILABLE_DURING_HANDSHAKE);
> +		    session->internals.recv_state != RECV_STATE_EARLY_START_HANDLING &&
> +		    !(session->internals.hsk_flags & HSK_EARLY_DATA_IN_FLIGHT)) {
> +			/* this additional check is to avoid a mutex for applications sending
> +			 * and receiving in parallel. */
> +			if (!session->internals.initial_negotiation_completed)

Strictly speaking, you can't have a check on a non-atomic variable/non locked context if the variable was potentially modified by another thread. Here, your compiler is completely free to remove it if it can prove that this check isn't relevant in a monothread context.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/935#note_144682392
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20190225/c101087b/attachment-0001.html>