Repository navigation
v0.9.7
-
Implement
task_local!inshuttle-tokio, withtask::LocalKeyandtask::futures::TaskLocalFuture.shuttle-tokioused 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. Requiresshuttle0.9.7. (#380) -
Add
current::try_get_current_task, a non-panickingget_current_taskforDrophandlers andtracingsubscribers. It returnsNoneoutside of an execution and while Shuttle updates its own state. (#380) -
shuttle::thread::LocalKey<T>is nowUnwindSafeandRefUnwindSafefor everyT, likestd::thread::LocalKey. It used to take both fromT, so a type that held a reference to a key, such asshuttle-tokio'stask::LocalKey, was notUnwindSafeif the key's value was aRefCell. (#380) -
shuttle-tokio'stask::try_idno longer panics outside of a Shuttle execution or while Shuttle updates its own state, as tokio's never panics. It returnsNonein both, even in a task, as in atracingsubscriber 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
timeoutthat fired, can use them. Ashuttle-tokiotask_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 itsJoinHandleis 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
tracingsubscriber at TRACE level calls into Shuttle, for example to read ashuttle-tokiotask-local.ExecutionState::try_withasked 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 atracingsubscriber of the TRACE event that Shuttle emits there. The slot created in between is kept. (#380) -
Publish
shuttle0.9.7,shuttle-engine0.1.5 andshuttle-std0.1.4, which between them have the changes to Shuttle above, andshuttle-tokio-impl-inner0.1.5 andshuttle-tokio-impl0.1.2, which have the newtask_local!.shuttle-stdrequiresshuttle-engine0.1.5, andshuttlerequires both, so that upgrading to 0.9.7 brings the fixes with it.shuttle-engine0.1.5 still works with thethread_local!of oldershuttles, asLocalKey's fields are unchanged.shuttle-schedulersis unchanged at 0.1.1; it takesshuttle-engineas^0.1.1, so it builds against 0.1.5 as it stands. Inner requiresshuttle0.9.7, which hascurrent::try_get_current_task, andshuttle-engine0.1.5, and impl requires inner 0.1.5. Inner stays a 0.1 release, so that crates that take it as^0.1, asdial9-coredoes, share it withshuttle-tokio. But it changes whattask::futures::TaskLocalFutureis, from tokio's type to its own, and impl 0.1.1 re-exports tokio'stask_local!over the glob re-export of inner. So if inner is updated on its own, withcargo update -p shuttle-tokio-impl-innersay,task_local!is still tokio's, and code that namesTaskLocalFuturefails to compile. Updateshuttle-tokio-implto 0.1.2 as well then, as a plaincargo updatedoes.