I also have this concern, a full build interrupts are awesome for hang on
/canceling the job, but it’s really hard to get it completely right, sometimes
confuses a lot for some code that should not care about these interrupts
signals.
Best,
Danny Chan
在 2019年10月17日 +0800 PM5:47，Vladimir
Roman Elizarov raises valid points re 'interrupts are too hard (or even
impossible) to get right':
https://twitter.com/relizarov/status/1184460504238100480
Vladimir
I agree with both points.
There are projects which do not handle interrupts in the best possible way.
My most recent experience was with H2 [1] where the database breaks
completely if a single thread is interrupted.
Best,
Stamatis
[1] https://github.com/h2database/h2database/issues/227
On Wed,
Statamis,
"cooperative to interrupt" sounds a nice idea, however, I have been bitten
multiple times by improper interrupt handling (not really with Calcite, but
with other projects).
In other words, it is good when everybody supports that.
However, the other libraries might receive unexpected
?
>>
>> Julian
>>
>>
>>> On Oct 8, 2019, at 10:48 AM, Haisheng Yuan
>> wrote:
>>>
>>> Make sense and quite reasonable.
>>>
>>> - Haisheng
>>>
>>> --
> How would we test this?
>
> Julian
>
>
> > On Oct 8, 2019, at 10:48 AM, Haisheng Yuan
> wrote:
> >
> > Make sense and quite reasonable.
> >
> > - Haisheng
> >
> > --------------
&
ote:
>
> Make sense and quite reasonable.
>
> - Haisheng
>
> --
> 发件人：Stamatis Zampetakis
> 日 期：2019年10月08日 18:04:17
> 收件人：
> 主 题：[DISCUSS] Make Enumerable operators responsive to interrupts
>
> Hel
Make sense and quite reasonable.
- Haisheng
--
发件人：Stamatis Zampetakis
日 期：2019年10月08日 18:04:17
收件人：
主 题：[DISCUSS] Make Enumerable operators responsive to interrupts
Hello,
There are many use-cases which require stopping
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
