fix: serialize killchannel map access to prevent concurrent-map crash

[ThiagoBauken]

Problem

killchannel (map[string]chan bool, declared in main.go) is accessed from two kinds of goroutines with no synchronization:

• HTTP request goroutines — Connect writes killchannel[txtid] = …; Disconnect, Logout and the admin delete path send on killchannel[txtid].
• The per-session startClient goroutine — reads killchannel[userID] in its loop and deletes the entry on kill.

Concurrent connects/disconnects therefore read, write and delete the same map at the same time. Go's runtime detects this and aborts the whole process with fatal error: concurrent map read and map write (or concurrent map writes). This is consistent with the crash reports in this area (#191, #153, #212).

This is separate from #242, which fixed the channel buffering; the map itself was never guarded.

Fix

Introduce a dedicated sync.Mutex (killchannelMu) and route every access through four small helpers:

• setKillChannel, getKillChannel, deleteKillChannel — lock only around the map op;
• signalKill — looks up the channel under the lock, then does the existing non-blocking send outside the lock.

The lock is never held while sending on or receiving from a channel, so a slow or absent receiver cannot block another session or deadlock. The startClient loop reads its channel via getKillChannel each iteration instead of indexing the map directly. No lifecycle behaviour changes — it purely makes the existing operations thread-safe, complementing the buffered-channel fix from #242.

Testing

• TestKillChannelHelpers — set/get/signal/delete cycle + safe no-op signal on a missing entry.
• TestKillChannelConcurrent — 100 users hammered from concurrent goroutines; under go test -race (CI) the old bare-map access reports the race, the guarded helpers are clean.
• go build ./... ✅ · go vet ./... ✅ · go test ./... ✅

[gemini-code-assist]

Code Review

This pull request replaces direct, unguarded access to the killchannel map with mutex-guarded helper functions to prevent data races, and adds concurrent unit tests. The review feedback highlights a critical concurrency bug and performance issue in wmiau.go where retrieving the kill channel inside a for loop on every iteration can lead to an infinite busy-loop, resource leaks, and high mutex contention. The reviewer suggests retrieving the channel once before entering the loop.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Critical Concurrency Bug & Performance Overhead

By calling getKillChannel(userID) inside the for loop on every iteration, two major issues are introduced:

1. Resource Leak & Infinite Busy-Loop (Bug): If a new connection is established for the same userID while an older startClient goroutine is still running, the older goroutine will retrieve the new connection's kill channel from the map. When a disconnect signal is sent, only one of the goroutines (non-deterministically) will receive the signal and exit. The remaining goroutine will continue running, and on its next iteration, it will find that the channel has been deleted from the map (getKillChannel returns nil). Reading from a nil channel blocks forever, causing the select to always fall through to the default branch and sleep for 1 second. This results in an infinite busy-loop that leaks CPU and memory indefinitely.
2. High Mutex Contention (Performance): Calling getKillChannel every second for every active session constantly locks and unlocks the global killchannelMu mutex, leading to severe CPU overhead and lock contention under high load.

Solution

Retrieve the kill channel once before entering the loop. This ensures the goroutine always listens to its own dedicated channel, preventing the leak/race bug and completely eliminating the repeated mutex locking overhead.

Suggested change

	for {
	kill, _ := getKillChannel(userID)
	select {
	case <-killchannel[userID]:
	case <-kill:
	kill, _ := getKillChannel(userID)
	for {
	select {
	case <-kill:

[ThiagoBauken]

Closing to consolidate my recent PRs into a smaller, focused set that's easier to review — I'll resubmit the changes grouped together. Sorry for the churn, and thanks!