Maybe rework run_in_worker_thread API for cancellation handling?

[njsmith]

Right now we just have a boolean flag, and it's name is maybe a bit misleading. Maybe it would be better to make it like:

run_in_worker_thread(..., on_cancel="abandon" or "carry-on")

and maybe there should be some option beyond these for actually signaling the thread? Like you can say on_cancel=my_list and we'll append something to the list if you're cancelled so you can occasionally do if my_list: abort()? Or maybe even append the cancel raiser function so it's like if my_list: my_list[0]()? But really this shouldn't be used for complex operations that are frequently returning to Python mode to check a value like this...

Even if we only want those two options for run_in_worker_thread, we probably want more options for the eventual run_in_worker_process -- like on_cancel="kill".

[oremanj]

I think #961 and #606 have a pretty good story for "ways for thread to notice it was cancelled". I'm pretty sure a theoretical run_in_worker_process() would never want to abandon the process on a cancellation, because then in buggy cases you can wind up with a worker process consuming lots of CPU in the background without noticing. Not sure there's anything left to do here, except maybe rename cancellable to something more descriptive like safe_to_abandon?

[smurfix]

+1 on the rename.

[njsmith]

Hmm.

run_in_worker_process wouldn't want to abandon the process on a cancellation, but there are still a few options... wait, send SIGTERM, etc. Not sure if that means it makes sense to combine them.

There's also an obscure case that bugs me – sometimes, when run_sync_in_worker_thread is cancelled, you want to run some code to try to abort the thread. For example, trio.hazmat.WaitForSingleObject calls a low-level blocking Win32 API in another thread, and when it's cancelled it wants to invoke a different low-level Win32 API to cause the thread to exit early. Currently we have a hack to handle this, where we use cancellable=True and then perform the abort on the way out, and it's more-or-less fine because WaitForSingleObject has no side-effects. But it's not quite the right thing theoretically, and it wouldn't work in cases where you need to put some abortable side-effecting operation in a thread (like maybe writing to stdout). So... maybe we should also support on_cancel=callable?

The cases where this is needed are super obscure and may not even matter in practice. And I think implementing it would be non-trivial. So it's not like a priority. But maybe we'll want it eventually?