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 > > > >
