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, Oct 16, 2019 at 10:10 AM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > 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 > "interruptedexception", and they might go off rails. > > For example, suppose you are implementing logger.info(...). What do you do > if you get an exception while logging? > Do you attempt to log it again? Do you attempt to log to System.err? > That is puzzling, and I have seen a case when the software performed 3 > attempts, then it stopped logging completely > because it thought "the logfile is broken". > > So: > 1) It might worth adding "interrupted" checks in the executors > 2) If Calcite ever uses .interrupt(), then it should be configurable (e.g. > to avoid cases when .interrupt() kills not that well-prepared code) > > Vladimir >
