Skip to content

v0.9.7

Choose a tag to compare

@sarsko sarsko released this 14 Oct 12:19
0ac892c
  • Implement task_local! in shuttle-tokio, with task::LocalKey and task::futures::TaskLocalFuture. shuttle-tokio used to re-export tokio's, which keeps a scope's value in a thread-local that every Shuttle task shares, so tasks saw each other's values. Each task now sees only the values of its own scopes, as in tokio, so a test that read a task-local outside of its own scope, such as in a task spawned from inside one, no longer passes by accident. Requires shuttle 0.9.7. (#380)

  • Add current::try_get_current_task, a non-panicking get_current_task for Drop handlers and tracing subscribers. It returns None outside of an execution and while Shuttle updates its own state. (#380)

  • shuttle::thread::LocalKey<T> is now UnwindSafe and RefUnwindSafe for every T, like std::thread::LocalKey. It used to take both from T, so a type that held a reference to a key, such as shuttle-tokio's task::LocalKey, was not UnwindSafe if the key's value was a RefCell. (#380)

  • shuttle-tokio's task::try_id no longer panics outside of a Shuttle execution or while Shuttle updates its own state, as tokio's never panics. It returns None in both, even in a task, as in a tracing subscriber that handles some of Shuttle's own events, where tokio's would return the task. (#380)

  • A future task that finishes now drops its future before its thread-locals, as an aborted one already did, so that the destructors of futures it still owns, such as the one inside a timeout that fired, can use them. A shuttle-tokio task_local! scope held that way is now dropped with its value set, as in tokio. Likewise, the output of a detached future task, and what a thread returns once its JoinHandle is gone, are now dropped before the task's thread-locals, as std drops a thread's, so that their destructors can use them. (#380)

  • Fix a stack overflow when the filter of a global tracing subscriber at TRACE level calls into Shuttle, for example to read a shuttle-tokio task-local. ExecutionState::try_with asked whether its event was enabled, which runs the filters, before it set the flag that stops an access from inside the event's handling from emitting it again. (#380)

  • Fix a "cannot reinitialize a storage slot" panic on the first use of a thread_local! in a thread, when the key was used again while its slot was being created: by its initializer, or by a tracing subscriber of the TRACE event that Shuttle emits there. The slot created in between is kept. (#380)

  • Publish shuttle 0.9.7, shuttle-engine 0.1.5 and shuttle-std 0.1.4, which between them have the changes to Shuttle above, and shuttle-tokio-impl-inner 0.1.5 and shuttle-tokio-impl 0.1.2, which have the new task_local!. shuttle-std requires shuttle-engine 0.1.5, and shuttle requires both, so that upgrading to 0.9.7 brings the fixes with it. shuttle-engine 0.1.5 still works with the thread_local! of older shuttles, as LocalKey's fields are unchanged. shuttle-schedulers is unchanged at 0.1.1; it takes shuttle-engine as ^0.1.1, so it builds against 0.1.5 as it stands. Inner requires shuttle 0.9.7, which has current::try_get_current_task, and shuttle-engine 0.1.5, and impl requires inner 0.1.5. Inner stays a 0.1 release, so that crates that take it as ^0.1, as dial9-core does, share it with shuttle-tokio. But it changes what task::futures::TaskLocalFuture is, from tokio's type to its own, and impl 0.1.1 re-exports tokio's task_local! over the glob re-export of inner. So if inner is updated on its own, with cargo update -p shuttle-tokio-impl-inner say, task_local! is still tokio's, and code that names TaskLocalFuture fails to compile. Update shuttle-tokio-impl to 0.1.2 as well then, as a plain cargo update does.