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.
   at System.Diagnostics.Process.get_StartInfo()
   at SomeTestUtility.WaitForSomeProcessToExit()

Summary of database isolation levels

Summary of different database isolation levels

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

How typeof(T) works in .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.

Does Go need async/await?

Does the go language need async/await support?

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.

Top secret .NET handles - Part 2 - Ref-Counted handles

Top secret .NET handles - Part 2 - Ref-Counted handles

Last time we talked about .NET dependent handle. It is a handle that promotes secondary if primary is promoted - as if there is a imaginary reference between them. This time let’s take a look at another secret handle - ref-counted handle. A ref-counted handle is a special handle that will become either strong or weak depending on the ref count. It’s only used in COM interop today internally in the CLR.

You can find its definition in gcinterface.h

    /*
     * REFCOUNTED HANDLES
     *
     * Refcounted handles are handles that behave as strong handles while the
     * refcount on them is greater than 0 and behave as weak handles otherwise.
     *
     * N.B. These are currently NOT general purpose.
     *      The implementation is tied to COM Interop.
     *
     */
    HNDTYPE_REFCOUNTED   = 5,

Top secret .NET handles - Part 1 - Dependent handles

Top secret .NET handles - Part 1 - Dependent handles

.NET publicly has documented 4 kind of handles:

  1. Weak (also called Short Weak) - Don’t keep target object alive and will return null when object is gone. The target will become null when the object enters for finalization.

  2. WeakTrackResurrection (also called Long Weak) - Don’t keep target object alive and will return null when object is gone. It’ll return the object even when the object is being finalized or resurrected.

  3. Normal (also called strong) - keeps target object alive. If you are not careful, you may leak the object.

  4. Pinned - Keeps the target object alive and prevents GC from moving this object around. Useful when you are passing this object to native code, as native code won’t know if GC moved it. Note that using a lot of pinning handles may degrade GC performance. The most common offender is pinned strings/arrays in interop calls.

You can also find them described in GCHandle enumeration.

However, besides these 4 types, there are actually more secret internal handle types that are not exposed. In this post I’ll be talking about dependent handle, and why it is totally awesome.

Calling C functions from Python - part 3 - deep dive into ctypes implementation in CPython

Calling C functions from Python - part 3 - deep dive into ctypes implementation in CPython

Last time we’ve looked at using ctypes to call C API, and writing extension module using Python/C API. Now we can finally tie these two together - looking at how ctypes is actually implemented using mix of Python/C API and Python code.

  • You can find CPython source code here.
  • ctypes’ C implementation is here
  • ctypes’ python implementation is here.

Calling C functions from Python - part 2 - writing CPython extensions using Python/C API

Calling C functions from Python - part 2 - writing CPython extensions using Python/C API

In my previous post we’ve briefly looked at using ctypes module to call C APIs. In this post let’s dive into a completely different approach - writing a C extension using Python/C API. From the C extension you can then call whatever C/C++ code you want. This is a pretty popular approach to expose a 3rd party C library as python module. The downside is this module would only be loaded by CPython, which is usually not a big issue - unless you use other Python implementation like PyPy.

Pagination