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.
When you use Task.WhenAll, it will continue execution based on the last task that completed. This means it can continue on some arbitrary thread.
In the above case, the second TaskCompletionSource didn't specify "RunContinuationsAsynchronously" and since it finishes last, WhenAll resumes when the second thread calls TrySetResult.
If you're calling TrySet* make sure you're either dispatching the calling code to the thread pool. If you're not doing this, make sure you know what the calling code can do and decide if that's ok. Ask yourself questions like "What happens if the caller blocks my thread?".
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I'm not sure about using redis as a queue, seems like blocking operations block the connection? Also, when using BROP to monitor multiple queues, you end up shuffling the queue names so the queue at the front of this list doesn't take priority (round robin?)
Or do you spin up multiple connections and balance the queues across them? It's a multiplexing problem (reminds me of HTTP/2).
I'm using System.Threading.Channels and Redis to expose a really nuget IAsyncEnumerable<T> implementation. Then using static interfaces to provide the RedisValue -> T.
Lets talk about events. We want to write some code that reacts when something happens. This pattern exists in many domains from UI programming to IoT to serverless. What do the programming patterns for this look like today in #dotnet and #csharp?
We create a button (imagine this was referenced by a form or some UI component), then hook up an event handler and write to the console when a button click event happens. This is the one of the most popular and idiomatic event handling paradigms in .NET today.
It's existed for years and years in many different programming languages and domains. There may or may not be data associated with these events.
Our hackathon project this year was working on making it easier to incrementally migrate large ASP.NET projects to https://t.co/4PmXMQN7SX Core. Here's the MVC music store app: #dotnet#aspnetcore
Most pages are running on .NET Framework but the shopping cart is managed by ASP.NET Core. This application is 10 years old and using both technologies at the same time, sharing source where possible.
This is made possible because both applications are running in the same IIS pipeline using different modules. It's sharing session and auth with the existing application without many changes to it. The ASP.NET Core application is part of the larger application.
ConcurrentDictionary - Good read speed even in the face of concurrency, but it’s a heavyweight object to create and slower to update.
Dictionary with lock - Poor read speed lightweight to create and “medium” update speed.
Dictionary as immutable object - best read speed and lightweight to create but heavy update. Copy and modify on mutation e.g. new Dictionary(old).Add(key, value)
Reflecting on my immigration journey this morning and for anyone else in the same situation it was:
F1/OPT 1 year (student visa) -> H1-B 5 years (work via) -> Green Card 7 years (permanent resident) -> Citizen yesterday. No more immigration anxiety 😅
Since being on a student visa I've always been worried about not being able to enter the US for some random reason or the other (plus being a black immigrant). Travelling with an excess amount of paperwork to prove you belong here.
When I joined Microsoft in 2008, there were huge layoffs and I was sure I was going to be in that set of people. Why not lay off the new employees (and immigrants at that)? It didn't happen and I was thankful. Microsoft sponsored my H1-B and Green card.