Existing cancellation mechanism works fine for code that embraces async/await, but it doesn't work for synchronous code path since it requires code to yield to the event loop to handle cancellation notification.

This new mode is for those people who want to use cancellation with synchronous code path at the expense of file I/O.

The existing cancellation mechanism is still there and works as it used to be, so if the event loop gets to the cancellation check first, it will still work.

if two ends of JSON-RPC uses different cancellation mode, it will fall back to existing cancellation mode (cancel notification)

… in the protocol repo

and added cancellation tests

…ssible.

This is a best-effort approach, so it doesn't guarantee all files will be deleted at the end.

For example, if the client-side tries to raise cancellation right after the server responded, but before the client-side responded to the reply, then it could create a cancellation file that no one is looking for.

Another case would be if cancellation is raised, but no one in the server-side checked the cancellation, then the server wouldn't know that cancellation is raised, and the cancellation file created won't be deleted.

But the owner of the JSON-RPC connection owns the cancellation file folder, so he should take care of resources left at the end of the session.