Concurrency on Prateek Sharma

The Go Programming Language

Tue, 01 Sep 2026 00:00:00 +0000

TODO: Add review / notes once read.

Daemon threads for WebSocket keepalives

Sat, 29 Aug 2026 00:00:00 +0000

A WebSocket connection that needs periodic pings to stay open shouldn’t run that ping loop on a plain, non-daemon thread. In the WazirX Java connector , the ping thread is started onOpen and marked setDaemon(true) before starting it:

pingThread = new Thread(new PingMessage(this));
pingThread.setDaemon(true);
pingThread.start();

A non-daemon thread keeps the JVM alive until it finishes. If a caller opens a socket, forgets to close it, and the rest of the application shuts down, a non-daemon ping thread will keep the process running indefinitely. A daemon thread just gets killed when everything else is done — which is the right default for background keepalive work that isn’t itself the point of the program.

Two-sided membership needs one lock, not two

Thu, 27 Aug 2026 00:00:00 +0000

Goroomlib models a relationship that points both ways: a Room holds a map of its users, and each User holds a list of the rooms it’s in. That redundancy is deliberate — both lookups need to be O(1) — but it’s also the whole bug surface.

The first version

AddUserToRoom did the obvious thing:

func (s *RoomService) AddUserToRoom(roomName string, user *User) {
    room := s.rooms[roomName]

    room.mu.Lock()
    room.users[user.ID] = user
    room.mu.Unlock()

    user.mu.Lock()
    user.joinedRooms = append(user.joinedRooms, roomName)
    user.mu.Unlock()
}

Each side is individually locked, so go vet and the race detector on a simple test are both happy. But there’s a window between the two critical sections where the room says “user is here” and the user says “I’m not in that room.” Anything that reads both — say, a disconnect handler that walks user.joinedRooms to remove the user from each — can run in that window and leak the membership.

Goroomlib

Sun, 23 Aug 2026 00:00:00 +0000

Across the poker platforms I’ve worked on at Adda52 and Mind Sports League, one shape kept showing up: users joining a table, leaving it, sending messages to everyone at it, and the server keeping track of who’s where. Every time I touched a new real-time feature, I ended up rewriting the same User and Room bookkeeping from scratch. I wanted to pull that pattern out once, get it right, and stop reimplementing it.