sayrer

Issues in "Feral Concurrency Control" (SIGMOD 2015) Oct 20, 2026

A close reading of Bailis et al., Feral Concurrency Control: An Empirical Investigation of Modern Application Integrity (SIGMOD 2015), ordered roughly by severity.

Internal contradictions and arithmetic errors

• 249 duplicates is impossible under the paper's own bound. §5.1 says that with P concurrent validations, each key can be inserted at most P times, so there are at most P−1 duplicates per key. In the stress test with 3 Unicorn processes and 100 keys, that caps duplicates at 200. The paper reports 249. Either the bound is wrong or the measurement is. (The 2-process result, 70 duplicates across 70 keys, is consistent with the bound.)

• "Over 9950 uses of application-level validations" (§1) contradicts "60 out of 3505 validations" (§4.1). 3505 checks out: Table 1 sums to 3445, plus 60 custom validations, and the Table 2 average of 52.31 × 67 apps is about 3505. Even validations plus associations only gets to about 9727, not 9950.

sayrer

//! Björn Höhrmann's "Flexible and Economical UTF-8 Decoder", in safe Rust.
//! <https://bjoern.hoehrmann.de/utf-8/decoder/dfa/>
//!
//! This is the 2010 variant (states pre-multiplied by 12, after Rich Felker),
//! with one change: the transition table is padded to 256 entries so that
//! `TRANS[state.wrapping_add(class) as usize]` indexes a `[u8; 256]` with a
//! `u8`-derived index. The compiler can prove that's in bounds, so the hot
//! path has no bounds checks and no `unsafe`.
//!
//! Original C: Copyright (c) 2008-2010 Bjoern Hoehrmann <bjoern@hoehrmann.de>,

sayrer

⏺ Numbers in hand:

  - iai/callgrind bench: can't run on this M1 — no valgrind on Apple
    Silicon (gungraun-runner/valgrind absent). So the instruction
    counts in the doc are inherently the AMD/Linux machine's; this M1
    can only give wall time.
  - M1 wall (v5_rotate_wall, criterion): 10.55 ms [10.52–10.59], tight.
    Was 11.63 → −8.8% on M1.
  - AMD (doc, callgrind): −30.3% instructions, −47% RAM hits, −30% est.
    cycles.

sayrer

Grammar and Spell Check: draft-ietf-tls-mlkem-08

Spelling / Grammar

1. Doubled "and and" — In both the meta-description and the Abstract: "as NamedGroups and and registers IANA values" should read "and registers". This appears twice (meta-description and section-abstract-1).

2. Reference inconsistency (§4.2.8) — The Introduction cites key_share Section 4.2.8 of RFC8446bis, while Section 4 and Section 4.2 cite Section 4.2.7 / 4.2.8 of plain RFC8446. Inconsistent reference target.

Reference / Citation Bugs

sayrer

run a grammar and spell check on https://www.ietf.org/archive/id/draft-ietf-tls-mlkem-08.html

4:44 PM I'll fetch the draft and check it for grammar and spelling issues.

Searched the web Searched the web Issues found:

sayrer

⏺ Results in. Cross-package, so benchstat can't auto-pair them, but the numbers speak clearly:

Lazy DFA vs NFA-only: same workload, different branches

BenchmarkLazyDFAHotPath — 50 shellstyle patterns, ~55 events, cache warmed:

  ┌───────────────────────┬───────────────────────┬──────┬────────┐
  │        Branch         │        sec/op         │ B/op │ allocs │
  ├───────────────────────┼───────────────────────┼──────┼────────┤

sayrer

❯ let's make a plan to install Jenkins and set up one Mac and one Linux VM as agents                                                                                                                                
                                                                                     
  Listed 1 directory (ctrl+o to expand)                                                                                                                                                                             
                                                                                                                                                                                                                    
⏺ Here's a proposed plan. A few choices need your input before we commit to specifics — I've marked them with ?.                                                                                                    
                                                     
  Decisions to lock first      

sayrer

how hard is it to set up Jenkins on a mac, and run Linux and Windows VMs alongside them as agents10:02 AMClaude responded: The Jenkins controller part is genuinely easy — brew install jenkins-lts, get it running as a launchd service, plug your auth in, done in an afternoon.Assessed Jenkins setup difficulty across Mac hardware configurations and VM agentsAssessed Jenkins setup difficulty across Mac hardware configurations and VM agentsThe Jenkins controller part is genuinely easy — brew install jenkins-lts, get it running as a launchd service, plug your auth in, done in an afternoon. The friction is all in the agents, and how bad it gets depends mostly on the Windows side.
Linux agent: trivial. UTM (free, works fine on Apple Silicon) or Parallels, headless Ubuntu Server, OpenJDK 17, then add it as an agent over SSH from the Jenkins UI. SSH is the right transport — Jenkins manages the agent process for you, you don't have to maintain a separate launch agent on the Linux side. Realistically a few hours including

sayrer

      131 -        for hit in self.rtree.locate_in_envelope_intersecting(&envelope) {                                                          
      132 -            if self.trees[hit.data].contains(point) {                                                                               
      133 -                f(hit.data);                                                                                                        
      134 -            }                                                                                                                       
      135 -        }                                                                                                                           
      131 +        // Internal-iteration variant of `locate_in_envelope_intersecting`                                                          
      132 +        // walks the R-tree on the call stack instead of pushing children onto                                                      
      133 +     

sayrer

Reading the stack bottom-up: AppKit is in terminate: → _deallocHardCore:, which
walks the global NSHashTable of windows and releases each one. During one of
those releases, -[NSWindow dealloc] hit an NSAssert (that's what frames 0–3
are — __assert_rtn → abort → pthread_kill). So this isn't a random segfault or
an over-release into freed memory; it's AppKit's own invariant check firing
inside the window teardown path on app quit. The single most useful missing
piece is the assertion text itself. __assert_rtn writes the failing expression
and file:line to stderr right before abort(), and the full .crash / .ips file
usually has it in the Application Specific Information block near the top. Grab
that — it turns this from "something's wrong during quit" into a one-line