In addition to the LinkClock issue, would you mind adding documentation for schedAbs? New methods should be documented unless they are private.

I just had a quick coffee. :)

I just had a quick coffee. :)

Ha ha! OK... what happened was, I was just sitting down to add schedAbs myself, and then saw an e-mail that you had done it, and went to review it quickly.

I think that a prior SC maintainer would have preferred CondVar over 0.002.wait (out of a general preference for avoiding hardcoded wait times). For that matter, even the 0.001.wait within the Tasks are unnecessary; for the test, we only require the Task to awaken once, not twice. I guess I personally won't be that much of a stickler, but I do see their prior point that habitually consuming extra milliseconds in testing could cumulatively slow down the test suite more than you'd think.

So perhaps:

	test_play_with_AppClock {
		var ok = false;
		var cond = CondVar.new;
		var task = Task { ok = true; cond.signalAll };
		task.play(AppClock);
		cond.waitFor(0.1, { ok });
		task.stop;
		this.assert(ok, "Task plays with AppClock");
	}

Yes, I did see your suggestion further up. I had decided for simplicity – while I do understand conditions, I have to admit that I have to read three times the code needed to use them …

OK, so here is a test series that factors out the "complicated" bits.

@jamshark70 if you have the time, could you review it and if ok mark your change request as fulfilled?

@jamshark70 do you have any more requests for this PR?

LGTM 👍