[
https://issues.apache.org/jira/browse/ARROW-16178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521517#comment-17521517
]
Antoine Pitrou commented on ARROW-16178:
----------------------------------------
Can we step back a bit and reason about the underlying need here? I suppose it
is so that distinct threads computing a given operation operate on different
scratch spaces, and also to be able to reconcile those scratch spaces at the
end (i.e. merge the results)?
> [C++] Add a ThreadLocalState concept built on thread local
> ----------------------------------------------------------
>
> Key: ARROW-16178
> URL: https://issues.apache.org/jira/browse/ARROW-16178
> Project: Apache Arrow
> Issue Type: Sub-task
> Components: C++
> Reporter: Weston Pace
> Assignee: Weston Pace
> Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The ThreadLocalState is tied to an executor and, on creation, creates a state
> for every thread in the executor. In order to quickly access a particular
> thread's state we need a way to get a thread index (the index of the thread
> in the executor). Historically we used ThreadIndexer and this JIRA
> introduces a new approach using thread local.
> Similar to the ThreadIndexer this thread local state concept will fail when
> the capacity is resized during a run.
> Similar to the ThreadIndexer this concept won't work too well for serial
> execution until ARROW-15732 is resolved.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
