.NET APIs you didn't know existed. StringBuilder.GetChunks docs.microsoft.com/en-us/dotnet/a…. You can use this API to get access to the internal buffer of the StringBuilder instead of turning it into a String. #dotnet
StringSplitOptions.TrimEntries docs.microsoft.com/en-us/dotnet/a…. Ever split a string and didn't want to trim each entry? Me too, now you can use this enum to do it!
Process.WaitForExitAsync docs.microsoft.com/en-us/dotnet/a…. If you're ever written the code to properly wait for a process to exit you'll it's fraught with errors. This makes it easier.
Writing code that deals with paths? Tired of having detect trailing slashes? Path.TrimEndingDirectorySeparator was made for you docs.microsoft.com/en-us/dotnet/a…
There are some common issues I see when people use ConcurrentDictionary:
- Dealing with the fact that GetOrAdd executes the creation callback more than once. This means if you create something expensive, it'll happen more than once. (this is documented) #dotnet
- If you create a disposable object in your factory and it gets called multiple times, the created objects will never be disposed.
- Making sure asynchronous factories and are called once. (making all callers wait on the same value).
Here's a contrived example of the resource leak. The code runs a couple of concurrent operations and uses GetOrAdd to cache a FileStream. This will call File.OpenRead potentially multiple times which will result in opening a handle to the resource and not disposing it.
Week 2 of analyzing how goroutines pause and resume and how the networking stack and other subsystems interact with the primitives exposed by the runtime.
One of the things I appreciate about C# is how many low level features are directly exposed to users. #golang#dotnet
In golang, it's not possible for you to implement pausing and resuming of goroutines other than by using the primitives go offers, channels, network IO, timers (sleep). This is fine for most applications but comes with additional overhead.
I also learned that go's GC doesn't move pointers and therefore there's no way to pin memory when working with C interop. There's no equivalent to passing around a GCHandle in go, just don't pass things with managed pointers to C.
Tonight, we'll discuss some of the little known low level optimizations made to async/await in .NET Core 3.x! By now, most of you know what asynchronous programming is, if not look at docs.microsoft.com/en-us/dotnet/c…#dotnet
As a primer, remember I can write asynchronous logic in a sequential manner. The keywords async/await originated in C# 5.0 8 years ago, though there were inspirations in other languages that lead to this final syntax. I get sad when people think javascript invented async/await ;)
To see what the compiler generates, we decompile the async state machine back into C# to compare sharplab.io/#v2:D4AQTAjAsA…. The state machine keeps track of local state and all of the required context to pause and resume at each await point.
Somethings that we tried to change when building ASP.NET Core:
- Removing all first chance exceptions (where possible).
- Remove scanning all assemblies on Startup to find things (controllers/hubs/plugins/etc). We try to do a bulk of the work during build...
So that startup time isn't impacted by the scan and load all types in all assemblies.
- Code over configuration. Configuration is read and configured by imperative code.
- DI everywhere, anywhere we call your code, you can inject dependencies
- No static APIs, the entire framework is testable and uses constructor injection. Places that use the service locator pattern only do so because they themselves are factories. The root of the universe is the is DI container.
One of the beauties of shared abstractions is once the ecosystem starts to take advantage of them, adding value becomes that much more impactful. This is one of the goals of Microsoft.Extensions.* that we built while developing ASP.NET Core #dotnetcore#aspnetcore
It serves as a building block for what we call "application models" and attempts to handle the boring boilerplate and cross cutting concerns like dependency injection, logging and configuration.
The strategy is multi pronged:
- Introduce libraries with minimal dependencies that other libraries can take a dependency on without too much burden (ILogger, IConfiguration, IOptions, IHostingEnvironment) etc.
More Task and async gotchas! This code will dead lock.
Just a refresher, when you use a TaskCompletionSource, calling Set* or TrySet* will execute the continuation on that thread. Think of it like an event handler, you're triggering the event inline.
There's a new option that was introduced in .NET 4.6 and all of .NET Core that allows you to specify that the continuation should be dispatched to the thread pool.