I didn’t realize that it was cooperative. I now see that we need to call Thread.interrupted(), and that no exceptions will be thrown (unless we call a method that declares ’throws InterruptedException’).
It seems doable. Julian > On Oct 9, 2019, at 3:55 PM, Stamatis Zampetakis <zabe...@gmail.com> wrote: > > By using interruption, and not forcefully stopping threads, I think we can > avoid corrupted data-structures etc. > > "Thread interruption is a cooperative mechanism. The cooperative approach > is required because we rarely want a task, thread, or service to stop > immediately, since that could leave shared data structures in an > inconsistent state. Instead, tasks and services can be coded so that, when > requested, they clean up any work currently in progress and then > terminate." [1] > > I don't think it will be easy to implement a pause-resume mechanism. I > tried a couple of times for other use-cases but not with a big success. > > "There is nothing in the API or language specification that ties > interruption to any specific cancellation semantics, but in > practice, using interruption for anything but cancellation is fragile and > difficult to sustain in larger applications." [1] > > Based on the contract of the Enumerator calling close should release any > resources so if it is implemented right we shouldn't end up with resource > leaks. > > In my mind we should check for interrupts only at the slowest part(s) of > the operation. I am hoping that this is not the initialization or tear down > phase but remains to be verified. > > Regarding tests, I think it depends how we will implement the cancellation. > For instance, if we decide to throw specialized exceptions then we can > enrich them with any additional information that could tell us exactly > where and when the interruption started. We can also inspect the stack > trace of running threads and verify that there is no Enumerable code > running after interruption. Sure is that we cannot rely on the correctness > of the returned results so far (if there are). > > Best, > Stamatis > > > [1] Java Java Concurrency in Practice by Brian Goetz > > On Tue, Oct 8, 2019 at 8:56 PM Julian Hyde <jh...@apache.org> wrote: > >> Is there a possibility that data structures will be corrupted, if a thread >> is interrupted in the middle of an operation? >> >> Supposing that we allow resume, is it possible to safely resume after an >> interrupt? >> >> Supposing that we do not allow resume, and instead call close on the root >> Enumerable, is it possible to guarantee each Enumerator cleans up after >> itself? >> >> Is there a period during the lifecycle of a tree of Enumerable objects >> (e.g. initialization, tear down) where we do not allow interrupts? >> >> How would we test this? >> >> Julian >> >> >>> On Oct 8, 2019, at 10:48 AM, Haisheng Yuan <h.y...@alibaba-inc.com> >> wrote: >>> >>> Make sense and quite reasonable. >>> >>> - Haisheng >>> >>> ------------------------------------------------------------------ >>> 发件人：Stamatis Zampetakis<zabe...@gmail.com> >>> 日 期：2019年10月08日 18:04:17 >>> 收件人：<dev@calcite.apache.org> >>> 主 题：[DISCUSS] Make Enumerable operators responsive to interrupts >>> >>> Hello, >>> >>> There are many use-cases which require stopping/cancelling the execution >> of >>> a query for various reasons. Currently, this can be done by launching the >>> query in a separate thread and then setting >>> DataContext.Variable.CANCEL_FLAG [1] accordingly. >>> >>> However if the tread executing the query gets interrupted through the >> usual >>> Thread.interrupt() mechanism the query execution will not stop since the >>> operators are not responsive to interruption. >>> >>> How do you feel about making Enumerable operators responsive to >> interrupts? >>> >>> Best, >>> Stamatis >>> >>> [1] >>> >> https://github.com/apache/calcite/blob/3f54108b7dcd4d2b89fc42faab145e2f82883791/core/src/main/java/org/apache/calcite/DataContext.java#L87 >>> >> >>
