<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sun, Dec 17, 2017 at 2:49 PM Yury Selivanov <<a href="mailto:yselivanov.ml@gmail.com">yselivanov.ml@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> One caveat based on Tornado's experience with stack_context: There are times<br>
> when the automatic propagation of contexts won't do the right thing (for<br>
> example, a database client with a connection pool may end up hanging on to<br>
> the context from the request that created the connection instead of picking<br>
> up a new context for each query).<br>
<br>
I can see two scenarios that could lead to that:<br>
<br>
1. The connection pool explicitly captures the context with 'get_context()' at<br>
the point where it was created. It later schedules all of its code within the<br>
captured context with Context.run().<br>
<br>
2. The connection pool calls ContextVar.get() once and _caches_ it.<br>
<br></blockquote><div><br></div><div><br></div><div>3. The connection pool has a queue, and creates a task for each connection to serve requests from that queue. Naively, each task could inherit the context of the request that caused it to be created, but the task would outlive the request and go on to serve other requests. The connection pool would need to specifically suppress the caller's context when creating its worker tasks. </div><div> </div><div>The situation was more complicated for Tornado since we were trying to support callback-based workflows as well. Limiting this to coroutines closes off a lot of the potential issues - most of the specific examples I can think of would not be possible in a coroutine-only world. </div><div><br></div><div>-Ben</div></div></div>