Not sure if MzScheme's kill-thread is guaranteed to kill a thread "instantly"? If not, then you have a race condition: you schedule a thread to be killed, but it maybe has just enough time to enter an atomic block before it dies.
But you're on the right track though. We actually don't want to kill a thread in the middle of an atomic... in your very first example, (thread:atomic (while t)), it would be a bug if kill-thread did break that loop. The whole point of "atomic" is that the operation completes before other threads see the result.
So the desired behavior is if a thread is "killed" in the middle of an atomic block, it should finish the block (and release the lock in the normal way), and then die.
The MzScheme documentation web site is down at the moment so I can't look now, but if I recall there is some kind of break or signal mechanism in MzScheme that might help.
That doesn't help if you want to kill a thread which is stuck (or just taking a long time) within an (atomic ...) expression, which seems to me an important use case. Unfortunately the plt doc website appears to be down now, otherwise I'd look into solving it myself.
There shouldn't be a way to interrupt an atomic operation, because then it won't be atomic.
Your elegant solution to make kill-thread atomic is a good one, if the "killed" thread is in fact guaranteed to be terminated instantly... I'll have to look into it to see if I can find out.
There shouldn't be a way to interrupt an atomic operation, because then it won't be atomic.
An interruptable atomic is basically a transaction that can be rolled back. If it gets interrupted nothing is changed. Probably doesn't make sense to run it from anywhere but kill-thread and similar operations.
To restate my original point: reasonable semantics for atomic are that threads inside atomic can't be killed. How to kill long-running atomics is a separate issue, needing a lot more engineering.
