5 ms·

What would be Tokios equivalent in .net/C# ?

by urza 6y ago

deleted 6y ago
[deleted]
steveklabnik 6y ago
The direct equivalent is the async runtime part of the .net/C# runtime, that is, it's built-in there, but is a library here.
Xevi 6y ago
C#/.NET has all of this already. You don't have to import anything else to use async/await.
- dragonwriter 6y ago
  [deleted: man, was that a dumb comment]
  - jayd16 6y ago
    No I think you're mistaken. You can rewrite pretty much every part of the system. You can write your own synchronization, you can write your own scheduling, you can write custom awaiter implementations. Its very pluggable. You might be able to argue that its even more pluggable than Tokio because the system has the concept of current context and attaching a task to it. Library code can use your custom scheduler. You can even throw away the Task type and create your own future type that works with the async/await syntax but of course no library would be able to pick that up.
  - tick_tock_tick 6y ago
    Of course it does just because C# comes with all the bells and whistles doesn't mean you can't write your own in it. https://docs.microsoft.com/en-us/dotnet/api/system.threading.tasks.taskscheduler?view=net-5.0 https://docs.microsoft.com/en-us/dotnet/api/system.threading...
pas 6y ago
In .NET you have the low-level runtime machinery implemented in the CLR (Common Language Runtime), but the transformation from async-await to state machine code is done completely at compile time. Basically, just like C# (and VB.NET and C++ .NET task/then) provides syntax and semantics for async-await, Rust provides it at language level too. (And it defines how the compiler transforms it into Future objects.) But, since Rust doesn't have a mandatory runtime, something needs to implement the low-level stuff that knows what to do with these Future objects. (In Tokio you have a work-stealing threadpool, but maybe in smaller runtimes you don't need all that fancy stuff for high-throughput, you just need small binary size, so there's a runtime/library called "smol" that's main feature is that it's a small async runtime.) In the CLR as far as I know there are Task objects, which basically correspond to Rust's Future objects. One interesting low-level difference (similarity?) is that in the CLR there's an explicit callback support by the runtime (to wake up Task objects - which can lead to deadlocks if they are scheduled on the UI thread), whereas in Rust Futures pass their own callbacks (called Waker) to a thing called the Reactor (which is basically the low-level implementation of the Executor, which binds to the OS/kernel level primitives, such as epoll or IOCP). And even though it's a "zero cost" abstraction, it still means there's a state machine, just like in .NET. Except it's built and "deadlock checked" at compile time. https://tooslowexception.com/wp-content/uploads/2020/05/thereisnothread.png https://tooslowexception.com/wp-content/uploads/2020/05/ther... https://www.red-gate.com/simple-talk/dotnet/net-framework/the-overhead-of-asyncawait-in-net-4-5/ https://www.red-gate.com/simple-talk/dotnet/net-framework/th...

What would be Tokios equivalent in .net/C# ?

by urza 6y ago

What would be Tokios equivalent in .net/C# ?

deleted 6y ago

[deleted]

steveklabnik 6y ago

The direct equivalent is the async runtime part of the .net/C# runtime, that is, it's built-in there, but is a library here.

Xevi 6y ago

C#/.NET has all of this already. You don't have to import anything else to use async/await.

dragonwriter 6y ago
[deleted: man, was that a dumb comment]
- jayd16 6y ago
  No I think you're mistaken. You can rewrite pretty much every part of the system. You can write your own synchronization, you can write your own scheduling, you can write custom awaiter implementations. Its very pluggable. You might be able to argue that its even more pluggable than Tokio because the system has the concept of current context and attaching a task to it. Library code can use your custom scheduler. You can even throw away the Task type and create your own future type that works with the async/await syntax but of course no library would be able to pick that up.
- tick_tock_tick 6y ago
  Of course it does just because C# comes with all the bells and whistles doesn't mean you can't write your own in it. https://docs.microsoft.com/en-us/dotnet/api/system.threading.tasks.taskscheduler?view=net-5.0 https://docs.microsoft.com/en-us/dotnet/api/system.threading...

pas 6y ago

In .NET you have the low-level runtime machinery implemented in the CLR (Common Language Runtime), but the transformation from async-await to state machine code is done completely at compile time. Basically, just like C# (and VB.NET and C++ .NET task/then) provides syntax and semantics for async-await, Rust provides it at language level too. (And it defines how the compiler transforms it into Future objects.) But, since Rust doesn't have a mandatory runtime, something needs to implement the low-level stuff that knows what to do with these Future objects. (In Tokio you have a work-stealing threadpool, but maybe in smaller runtimes you don't need all that fancy stuff for high-throughput, you just need small binary size, so there's a runtime/library called "smol" that's main feature is that it's a small async runtime.) In the CLR as far as I know there are Task objects, which basically correspond to Rust's Future objects. One interesting low-level difference (similarity?) is that in the CLR there's an explicit callback support by the runtime (to wake up Task objects - which can lead to deadlocks if they are scheduled on the UI thread), whereas in Rust Futures pass their own callbacks (called Waker) to a thing called the Reactor (which is basically the low-level implementation of the Executor, which binds to the OS/kernel level primitives, such as epoll or IOCP). And even though it's a "zero cost" abstraction, it still means there's a state machine, just like in .NET. Except it's built and "deadlock checked" at compile time. https://tooslowexception.com/wp-content/uploads/2020/05/thereisnothread.png https://tooslowexception.com/wp-content/uploads/2020/05/ther... https://www.red-gate.com/simple-talk/dotnet/net-framework/the-overhead-of-asyncawait-in-net-4-5/ https://www.red-gate.com/simple-talk/dotnet/net-framework/th...