Difference between global timeout and t.timeout

[make-github-pseudonymous-again]

I was just reading the issue #2384. Do I understand correctly that today the global timeout stops both sync and async tests, whereas t.timeout(...) can only stop async tests? And this would be because the global timeout runs in parallel of all tests, whereas t.timeout calls setTimeout in the same event-loop as the test it is from, hence it cannot trigger anything if the entire test is synchronous.

Do I understand correctly that this is the code for the global timeout?

ava/lib/api.js

Lines 75 to 91 in 97525a9

	if (apiOptions.timeout && !apiOptions.debug) {
	const timeout = ms(apiOptions.timeout);
	restartTimer = debounce(() => {
	// If failFast is active, prevent new test files from running after
	// the current ones are exited.
	if (failFast) {
	bailed = true;
	}
	runStatus.emitStateChange({type: 'timeout', period: timeout});
	for (const worker of pendingWorkers) {
	timedOutWorkerFiles.add(worker.file);
	worker.exit();
	}
	}, timeout);

Do I understand correctly that this is the code for t.timeout?

ava/lib/test.js

Lines 413 to 434 in 97525a9

	timeout(ms, message) {
	const result = assert.checkAssertionMessage('timeout', message);
	if (result !== true) {
	this.saveFirstError(result);
	// Allow the timeout to be set even when the message is invalid.
	message = '';
	}
	if (this.finishing) {
	return;
	}
	this.clearTimeout();
	this.timeoutMs = ms;
	this.timeoutTimer = nowAndTimers.setTimeout(() => {
	this.saveFirstError(new Error(message || 'Test timeout exceeded'));
	if (this.finishDueToTimeout) {
	this.finishDueToTimeout();
	}
	}, ms);
	}

It does not seem that there is a difference of logic between the global and t.timeout: both get restarted/refreshed whenever some activity/progress is detected (at least this seems to be the intent).

I think the logic could be merged, but this would require communication between test threads and the global timeout thread (the main thread?).

Let me expand on that. If you want t.timeout to work for synchronous tests one solution would be for t.timeout not to call setTimeout but to send the desired timeout to the same thread that handles the global timeout, and have the global timeout logic take into account individual timeouts of tests. For instance ignoring the global timeout for an individual test that has set a large t.timeout could be done since now all the timeout information is in a single place. This would require communication between test threads and the global timeout thread so that test threads can update timeouts, or notify progress (since I understand individual timeouts are refreshed (restarted, not canceled) each time a new assertion is made).

PS: I am researching this because I realized t.timeout could not be used in my synchronous tests. Or at least it appears so.
PPS: @novemberborn I just realized this solution is more or less what you suggest in #2384 (comment)

[novemberborn]

I hadn't actually considered blocking tests, but yes agreed with all the above 😄