[bryanjeal]

Three fixes for the kqueue backend, each with a reproducing test:

1. tick(0) now flushes pending EV_DELETE changes before returning. When a disarm occurs in the event-processing path, the EV_DELETE was queued but tick(0) exited before flushing it to the kernel, leaving a stale filter with a dangling udata pointer. Related to PR fix th .no_wait callback called multi times issue. #209.

2. Completions that return .rearm without kqueue registration (close, shutdown, no-threadpool fallback) now set state to .adding before re-entering the submissions queue. Previously the stale .dead state caused submit() to route through stop_completion (cancellation) instead of start() (resubmit). Related to PR queue: clear next before re-enqueue #170.

3. Defensive c.next = null before pushing kevent-returned completions to the completions queue in submit(). Prevents the queue.zig assertion failure when a completion is present in multiple queues concurrently. Fixes issue [bug] v.next is not proper cleared for re-enqueue a completion between different queues #169.

10 tests added (all fail without their respective fixes):

• tick(0) EV_DELETE flush (6 tests including a synchronous reproduction of the race path via cross-pipe callback write)
• rearm state for non-kqueue completions (1 test)
• queue re-enqueue invariants (3 tests)

[aravind-kumar]

Facing this issue almost everyday, can we prioritize this fix ?

[bryanjeal]

@mitchellh I am sorry if this is poor form, but is there anything I can do to move this PR forward?
Thank you in advance for your time.

[mattrobenolt]

The tick(0) deletion-flush hunk fixes a full TLS cancellation stall in baskingspot/tls#83.

Baseline f3d0a0e enables one existing kqueue test against libxev 9ce8e8e6. macOS run 34742256947 returns error.LoopStalled:

srv=closed/idle/released
cli=closing/idle/released active=0 events={ .read_canceled, .closed }

Candidate 7715eb5 applies only this hunk:

-if (wait == 0) break;
+if (wait == 0 and changes == 0) break;

Run 34742815211 executes the same test and passes. No test timing, callback, assertion, or other libxev hunk changes.

The stale level-triggered EOF re-enters the kevent event path. That path unconditionally decrements active after .disarm. The extra decrement consumes the active count for an in-flight thread-pool close. At zero, the loop gate prevents thread-pool completion migration.

The changed condition submits the staged EV_DELETE before the stale event can fire again. Evidence and source hashes live at baskingspot/tls@e8f6536.

This result validates the deletion-flush hunk only. It does not validate the other two hunks or a separate kqueue EBADF probe.

[mattrobenolt]

Follow-up: the deletion-flush hunk also fixes both ztls write-cancellation variants on kqueue.

With only that hunk, macOS run 34819771384 executes and passes these tests:

• Abortive close with a read in flight.
• Abortive close with a write in flight.
• Orderly close with a write in flight.

Without the hunk, isolated runs produce an integer-overflow panic in each write test. The runner reports only the panic address, so this result does not prove the exact source line.

ztls now pins this PR at 7497c85 in baskingspot/tls@c359f8d. Its macOS lane gates all four cancellation variants. Full evidence and hashes live under docs/research/XEV_KQUEUE_83/20260914-production/.

[endel]

I've also created a PR that touches .rearm here #245 with the help of Opus 5, I'm not sure which solution is the most correct.