A new build and a new structured concurrency API

[Alan Bateman]

On 15/11/2021 22:01, Mike Rettig wrote:
> :
>
> I've tried to use interrupts for cancelling. Interrupt handling code is
> often buried in third party code. To use interrupts I had to find and
> verify that all the interrupts were handled "correctly". It gets even
> trickier when code paths reach points that should no longer be cancelled.
> Rather than using interrupts, it is usually a much better approach to
> create explicit api's that support cancels (e.g. cancel a long running
> network operation by closing the socket).
As Ron said, cancellation is an area that requires further exploration, 
it's not this JEP. Prototypes to date did introduce a set-once cancel 
status and a means to poll it. Also worked through the relationship 
between the two mechanism so that cancellation caused the thread to be 
interrupted, the equivalent of Future::cancel(true), and necessary to 
work with existing code that does cause blocking calls to wakeup. One of 
the main concerns is of course having two similar mechanisms in the API. 
That would have hard to explain to developers, esp. new developers, and 
one of the reasons why we have to be cautious.

You mention cancelling network operations by closing the socket. That is 
the InterruptibleChannel semantics where interrupting a thread blocked 
on a channels causes the channel to be closed and an exception to be 
thrown. This has been extended to the legacy Socket APIs, more details 
on that are in the draft JEP for Virtual Threads. There will of course 
be libraries that do not respond to Thread interrupt but that wouldn't 
change with a new cancel mechanism.

-Alan.