Enforce custom regex-engine timeout via an inline deadline instead of a thread-pool timer

[lahma]

Problem

The flaky test RegExpTests.PreparedScriptHonorsRegexTimeoutForCustomEngine intermittently fails on Windows CI (example run):

Expected RegexMatchTimeoutException within 15s, took 17.5s

A 1s prepare-time regex timeout was observed to fire only after 17.5s.

Root cause

The custom (QuickJS-port) regex engine — used for patterns .NET Regex can't handle, like the catastrophic-backtracking TestRegex — enforced its match timeout with new CancellationTokenSource(timeout). That source's timer callback runs on the thread pool. When the pool is saturated (parallel xUnit runs on a CI runner), the callback is starved and the token isn't cancelled until much later, so the interpreter keeps backtracking well past the requested timeout.

The delay is unbounded under load, so no test-side threshold can be made reliable while the timer approach stands — the fix has to be at the source.

I reproduced this directly under a flooded thread pool (net472):

mechanism	observed abort latency for a 1s timeout
old: CancellationTokenSource(1s) timer	25s+ (starved for the whole probe window)
new: inline Stopwatch deadline	~1.3s

Fix

Enforce the timeout with an inline monotonic deadline (Stopwatch.GetTimestamp()), checked at the interpreter's existing interrupt checkpoints (once per 10,000 opcodes) — exactly how .NET's own Regex enforces MatchTimeout (the code already claimed to "mirror" it). The interpreter thread is always scheduled while it spins, so the abort fires promptly regardless of pool pressure.

• RegExpInterpreter / JintRegExpEngine: thread a long deadline (absolute Stopwatch.GetTimestamp() value, NoDeadline = no timeout) instead of a CancellationToken; each checkpoint now calls CheckDeadline(deadline).
• RegExpPrototype.ExecuteWithTimeout / IsMatchWithTimeout: compute the deadline from the configured timeout instead of allocating a CancellationTokenSource + timer per call. On expiry an OperationCanceledException is still mapped to the same rich RegexMatchTimeoutException(input, source, timeout).

Bonus: removes a per-call CancellationTokenSource allocation + timer registration on the custom-engine path.

Internal-only change; no public API surface affected.

Testing

• Jint.Tests full suite — net10.0 3597 / net472 3534, all green
• Jint.Tests.PublicInterface — 114/114 on both TFMs
• Test262 ~RegExp subset — 3930/0
• Verified TestRegex still routes to the custom engine after Prefer .NET Regex for quantified groups without capture or lookaround hazards #2682's routing rework (so this test genuinely exercises the fixed path)
• The starvation reproduction above (1.3s vs 25s+) confirms the root cause

🤖 Generated with Claude Code