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
A non-exhaustive list of things not yet supported by shuttle-tokio:
fs, net, io: All of these are currently simply forwarded to tokio in order to make code which uses this functionality compile, though it will not work if one actually tries to use it under Shuttle. This will probably remain the case for fs and io, though there is a case to be made for adding functionality from net. We have thus far done network simulation by building atop of sync::mpsc, but it would be nice to have TCP/UDP support out of the box.
tokio Runtime modelling. Our modelling of tokio runtimes is not faithful, and this will be a gap for applications which utilize multiple runtimes or which have some particular runtime setup. When running under ShuttleTokio, a task is modelled as a thread, and we do no modeling of task to worker thread mapping (aka it's as if every task has its own worker thread).
tokio::test macro parameters: All of these are allowed to make things compile, but do not do anything when run under Shuttle.
time modelling (aka start_paused). ShuttleTokio does not do anything with regards to modelling of time, apart from providing the primitives, and a very simple built in time model. The plan is to merge Adding Time Models to Shuttle #217 and then have ShuttleTokio provide better time modelling via the underlying Shuttle functionality. This also means that the "explicit time management" offered in tokio via time::advance will most likely never be the preferred solution for time modelling with ShuttleTokio.
TODO: ShuttleTokio needs to be updated to have better out of the box support for time modelling once #217 is merged.
sync::broadcast. In general sync is pretty well supported, but there has yet to be anyone needing broadcast, so it has remained unimplemented.
RuntimeMetrics: All of these functions return 0. It would be nice to return correct information. Shuttle should be updated to accommodate.
Cooperative scheduling. There are some stubs that exist in order to make code which uses it compile, but in general cooperative scheduling is poorly supported, and any usage of it pretends that it doesn't exist.
A non-exhaustive list of things not yet supported by shuttle-tokio:
fs,net,io: All of these are currently simply forwarded to tokio in order to make code which uses this functionality compile, though it will not work if one actually tries to use it under Shuttle. This will probably remain the case forfsandio, though there is a case to be made for adding functionality fromnet. We have thus far done network simulation by building atop ofsync::mpsc, but it would be nice to have TCP/UDP support out of the box.Runtimemodelling. Our modelling of tokio runtimes is not faithful, and this will be a gap for applications which utilize multiple runtimes or which have some particular runtime setup. When running under ShuttleTokio, a task is modelled as a thread, and we do no modeling of task to worker thread mapping (aka it's as if every task has its own worker thread).tokio::testmacro parameters: All of these are allowed to make things compile, but do not do anything when run under Shuttle.start_paused). ShuttleTokio does not do anything with regards to modelling of time, apart from providing the primitives, and a very simple built in time model. The plan is to merge Adding Time Models to Shuttle #217 and then have ShuttleTokio provide better time modelling via the underlying Shuttle functionality. This also means that the "explicit time management" offered in tokio viatime::advancewill most likely never be the preferred solution for time modelling with ShuttleTokio.sync::broadcast. In generalsyncis pretty well supported, but there has yet to be anyone needingbroadcast, so it has remained unimplemented.RuntimeMetrics: All of these functions return 0. It would be nice to return correct information. Shuttle should be updated to accommodate.