Skip to content

Blog

Go1.23 Timer Unbuffered Channel Changes

When I wrote this blog, go has just released go1.25rc2 and go1.23 is quite a long time ago release. In go1.23 release note, go team shares that Go 1.23 makes two significant changes to the implementation of time.Timer and time.Ticker. This blog focuses on the second change:

the timer channel associated with a Timer or Ticker is now unbuffered, with capacity 0. The main effect of this change is that Go now guarantees that for any call to a Reset or Stop method, no stale values prepared before that call will be sent or received after the call.

It will talk about why buffered channel is a problem, why unbuffered channel is used, the cases affected and how go implements this change.

Working Dir in Std Os Package

Go standard library provides os pacakge to trackle with os related concepts, for example, the working dir. Working dir is a os level concept rather than a concept maintained by os package. Indeed, os package doesn't reinvent the wheel but rely on the operation system to tackle it.

Working dir is a concept for a process rather than an executable. So statement "the working dir of binary ./bin/server is ~/workspace/server" is totally wrong.

Get Correct Module Name via Trie-Style Structure

Go language supports to put modules under a VCS, such as github. Usually, one git repo contains one go module and multiple packages under this module. However, this is not always correct because Go allows you to put multiple modules under the same project, and Go helps to find these modules via its path. A typical example is repository go.opentelemetry.io/otel, which contains huge amount of modules.

In my real senario, given a list of used modules parsing from go.mod, and a package name retrieving from import declaration, I want to know which module does this package belong to. strings.Contain isn't help at all because module paths have overlapped a lot.

Go Minimal Version Selection Notes

This is a reading note to summarise the build list and dependency requirements of minimal version selection of go. If you want to learn more about minimal version select(MVS), please read the documentation and design docs below.

In short, MVS produces the build list as output, the list of module versions used for a build. The "minimal" in MVS means it selects the minimal version of each module that satisfies all requirements, instead of automatically choosing the highest available version. For example, if the requirements are "v1.1, v1.2, v1.3", the version v1.3 is the minimal version that satisfies all requirements. According to the MVS, v1.3 is selected.