[Python-Dev] PEP 567 -- Context Variables

[Ben Darnell]

On Sun, Dec 17, 2017 at 2:49 PM Yury Selivanov <yselivanov.ml at gmail.com>
wrote:

> > One caveat based on Tornado's experience with stack_context: There are
> times
> > when the automatic propagation of contexts won't do the right thing (for
> > example, a database client with a connection pool may end up hanging on
> to
> > the context from the request that created the connection instead of
> picking
> > up a new context for each query).
>
> I can see two scenarios that could lead to that:
>
> 1. The connection pool explicitly captures the context with
> 'get_context()' at
> the point where it was created. It later schedules all of its code within
> the
> captured context with Context.run().
>
> 2. The connection pool calls ContextVar.get() once and _caches_ it.
>
>

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.

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.

-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171219/bfdc0729/attachment.html>