<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Thread Safety on Phosphor BBS</title>
		<link>https://phosphorbbs.net/tags/thread-safety/</link>
		<description>Recent content in Thread Safety on Phosphor BBS</description>
		<generator>Hugo</generator>
		<language>en-us</language>
		
		
		
		
			<lastBuildDate>Wed, 23 Sep 2026 00:00:00 +0000</lastBuildDate>
		
			<atom:link href="https://phosphorbbs.net/tags/thread-safety/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>The Case of the Blended Batches: A Race Hidden Inside a Replace</title>
				<link>https://phosphorbbs.net/blog/the-case-of-the-blended-batches/</link>
				<pubDate>Wed, 23 Sep 2026 00:00:00 +0000</pubDate>
				<guid>https://phosphorbbs.net/blog/the-case-of-the-blended-batches/</guid>
				<description>&lt;p&gt;The jterm thread-safety suite exists to answer one question: &lt;em&gt;can a widget survive being redrawn from one thread while another mutates it?&lt;/em&gt; It has run thousands of times across dozens of widgets, mostly to say yes. On the morning we cut the 0.1.1 release, it said no — and the test that failed wasn&amp;rsquo;t even the one that was broken.&lt;/p&gt;&#xA;&lt;h2 id=&#34;two-failures-two-days-apart&#34;&gt;Two failures, two days apart&lt;/h2&gt;&#xA;&lt;p&gt;The release gate runs the whole suite, 2,926 tests. The first full run failed one test: &lt;code&gt;FireworksTest.renderFrameProducesOutput&lt;/code&gt; — the fireworks animation was supposed to paint visible pixels after five frames and, once out of 2,926, it painted nothing. We re-ran the class in isolation: 12/12 green. Read the render path: fresh instance, deterministic math, five calls that each draw a rocket or particles. The failure looked like noise under load — the kind of flake you shrug at and re-run.&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
