Issue #8674: Interrupt Work Stealing

[hawkfish]

Check the work stealing loop for aborts so it doesn't loop forever.

fixes duckdblabs/duckdb-internal#140

[carlopi]

Confirm that fixes the issue, and makes sense to me.

I took a look at the code, question is whether this should not use some sort of general locking mechanism to avoid threading issues.

Say 2 threads both call StealWork (that internally has a lock, so will serve only one at a time), then the one that gets out throws right away, would that be also a problem?

---

edited: I though I had a solution, but it's just adding confusion (and it's wrong). So first maybe we try to check whether this is a problem at all
edit2: NOT A PROBLEM

[hawkfish]

tasks_remaining is atomic, so it doesn't need a guard, and interrupted is a single byte read, so it doesn't need one either.

I try to avoid locks because they are so heavyweight.

[carlopi]

tasks_remaining is atomic, so it doesn't need a guard, and interrupted is a single byte read, so it doesn't need one either.

I am not sure that helps. Say two threads both passed the check on !interrupted && tasks_remaining. Then one gets a task and throws, and the other will fail to steal work. What happens then?

[hawkfish]

When it fails, it will yield and the next loop will find the interrupt.

[carlopi]

Right, eventually (even a few cycle laters we don't care), it will eventually get out of the loop. Thanks for walking me through.

[hawkfish]

Right, eventually (even a few cycle laters we don't care), it will eventually get out of the loop. Thanks for walking me through.

Yeah its not the most resource-friendly way of doing it, but feature freeze (and VLDB) are approaching, so this seems good enough for now.

[samansmink]

lookin good!