Lines Matching +full:post +full:- +full:processing

5 QUIC processing is handled in a timely fashion regardless of whether an
12 per-connection mutex for the duration of any public API call which we forward to
15 the locking to every single public HL-related API call.
31 - **1. Application-controlled explicit locking.**
50 - **2. Handshake layer always belongs to the application thread.**
55   - `SSL_tick()` (or another I/O function) called by the application fully
58   - The assist thread performs a reduced tick operation which does everything
62   - This is rather hacky but should work adequately. When using TLS 1.3
66     post-handshake messages used by TLS 1.3 aren't relevant to QUIC TLS:
68     - Post-handshake authentication is not allowed;
70     - Key update uses a separate, QUIC-specific method;
72     - TLS alerts are signalled via `CONNECTION_CLOSE` frames rather than the TLS
85 - **3. Handshake layer belongs to the assist thread after connection begins.**
94   connection. We could selectively enable some important post-handshake HL calls
101   we don't implement for thread assisted post-handshake QUIC, we would