In other languages I have seen this called "async local"[1][2][3]. I'm not sure of any C++ implementations. Folly's fibers claim to have fiber-local variables[4] but I can't find the actual code to use them. I can't seem to find reference to the concept in boost's asio or cppcoro.
I've also seen libraries that had higher level contexts. For example, when working with HTTP servers there is often a pattern to have "request context" (e.g. you'll often find things like the IP address of the requestor, the identity of the calling user, etc.) I believe these are typically built on top of thread-local or async-local variables. I think some kind of async-local concept is a good idea. We already do some of this context propagation for open telemetry if I recall correctly. > - TaskHints (though that doesn't seem to be used currently?) I'm not aware of any usage of this. My understanding is that this was originally intended to provide hints to some kind of scheduler on how to prioritize a task. I think this concept can probably be removed. [1] https://learn.microsoft.com/en-us/dotnet/api/system.threading.asynclocal-1?view=net-7.0 [2] https://docs.rs/async-local/latest/async_local/ [3] https://nodejs.org/api/async_context.html [4] https://github.com/facebook/folly/blob/main/folly/fibers/README.md On Thu, Aug 24, 2023 at 6:22 AM Antoine Pitrou <anto...@python.org> wrote: > > Hello, > > Arrow C++ comes with execution facilities (such as thread pools, async > generators...) meant to unlock higher performance by hiding IO latencies > and exploiting several CPU cores. These execution facilities also > obscure the context in which a task is executed: you cannot simply use > local, global or thread-local variables to store ancillary parameters. > > Over the years we have started adding optional metadata that can be > associated with tasks: > > - StopToken > - TaskHints (though that doesn't seem to be used currently?) > - some people have started to ask about IO tags: > https://github.com/apache/arrow/issues/37267 > > However, any such additional metadata must currently be explicitly > passed to all tasks that might make use of them. > > My questions are thus: > > - do we want to continue using the explicit passing style? > - on the contrary, do we want to switch to a paradigm where those, once > set, are propagated implicitly along the task dependency flow (e.g. from > the caller of Executor::Submit to the task submitted) > - are there useful or insightful precedents in the C++ ecosystem? > > (note: a similar facility in Python is brought by "context vars": > https://docs.python.org/3/library/contextvars.html) > > Regards > > Antoine. >
