Lines Matching refs:to
4 In thread assisted mode, we create a background thread to ensure that periodic
9 access to this is extremely difficult.
12 per-connection mutex for the duration of any public API call which we forward to
13 the handshake layer. Since we forward a very large number of APIs to the
14 handshake layer, this would require a very large number of code changes to add
15 the locking to every single public HL-related API call.
35 calls, would be required to take the lock. As a special exemption, an
36 application is not required to take the lock prior to connection
37 (specifically, prior to the instantiation of a QUIC channel and consequent
42 probably happen prior to initiating a connection, things may not be that bad.
43 It would also only be required for applications which want to use thread
50 - **2. Handshake layer always belongs to the application thread.**
52 In this model, the handshake layer “belongs” to the application thread
53 and the assist thread is never allowed to touch it:
63 as the handshake layer, the only thing we actually need to worry about
65 which doesn't need to be acknowledged and isn't “urgent”. The other
66 post-handshake messages used by TLS 1.3 aren't relevant to QUIC TLS:
77 Thus so long as we don't expect our own TLS implementation to spontaneously
85 - **3. Handshake layer belongs to the assist thread after connection begins.**
87 In this model, the application may make handshake layer calls freely prior to
88 connecting, but after that, ownership of the HL is transferred to the assist
89 thread and may not be touched further. We would need to block all API calls
90 which would forward to the HL after connection commences (specifically, after
93 Con: Many applications probably expect to be able to query the HL after
99 connection. The work required is proportional to the number of APIs to be
100 enabled. Some APIs may not have ways to indicate failure; for such APIs which
