The tale of InvalidOperationException
This came up when I was helping someone looking into a strange issue. Recently some process dump capture tool started throwing InvalidOperationException:
Unhandled Exception: System.InvalidOperationException: Process was not started by this object, so requested information cannot be determined.
I’ve been always a bit confused about different isolation levels on databases. So I spent a bit of time going through them and summarize it in a post. This is both for myself and also hopefully will help others looking for similar information as well.
In this post we’ll talk about:
- Meaning of different isolation levels - read committed, repeatable reads, snapshot isolation, serializable
- How they use locks inside transactions
- How they affect performance
typeof(TSecret) - the secret magic behind .NET generics
In last post we’ve talked about how .NET does code sharing for reference types. This time let’s take a look at how
typeof(T) does its black magic.
In particular, how does the code knows what
typeof(T) is, in the presence of code sharing?
Obviously if there is no code sharing at all, each method instantiation are different and the code would be instantiated with the correct
typeof(T) code where T is a real type, it obviously would “just work”.
Before we dive into the implementation, let’s take a first crack at this problem and see what are the challenges.
Recently I’ve been spending a bit of time playing with Go language. Coming from a C++ and C# background, I’ve been wondering what does C# async await (C++ coroutines, or node.js await/promise - pick your choice), would look like in Go.
It turns out go does not need async/await - every thing can be synchronous by default.
Let me explain why I arrived at this conclusion.
But before that, let’s take a look at why we need the async/await in the first place.
In last post I’ve talked how one would start writing a emulator. Now it’s time to dive a bit deeper to see how we write the main loop to drive the emulation.