You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[XMLParser] Use TaskLocal for storing the current parser
Instead of thread-local storage, use `TaskLocal` to store the current
parser. This solves three issues:
1. If someone calls `XMLParser.parse()` with a new parser instance in
a delegate method call, it overwrote the current parser and wrote
it back after the call as `nil`, not the previous current parser.
This reentrancy issue can be a problem especially when someone uses
external entity resolving since the feature depends on the current
parser tracking. Using `TaskLocal` solves this issue since it tracks
values as a stack and restores the previous value at the end of the
`withValue` call.
2. Since jobs of different tasks can be scheduled on the same thread,
different tasks can refer to the same thread-local storage. This
wouldn't be a problem for now since the `parse()` method doesn't
have any suspention points and different tasks can't run on the same
thread during the parsing. However, it's better to use `TaskLocal`
to leverage the concurrency model of Swift.
3. The global variable `_currentParser` existed in the WASI platform
path but it's unsafe in the Swift concurrency model. It wouldn't be a
problem on WASI since it's always single-threaded, we should avoid
platform-specific assumption as much as possible.
0 commit comments