potiuk commented on pull request #22475: URL: https://github.com/apache/airflow/pull/22475#issuecomment-1077493164
We do have this: https://docs.python.org/3/library/os.html#os._exit > **[](https://docs.python.org/3/library/os.html#os._exit)os._exit(n) > Exit the process with status n, without calling cleanup handlers, flushing stdio buffers, etc. > Note The standard way to exit is sys.exit(n). [_exit()](https://docs.python.org/3/library/os.html#os._exit) should normally only be used in the child process after a [fork()](https://docs.python.org/3/library/os.html#os.fork).** It does not say "always" but this is quite a bit implied. Those exception are not rare and they are not `something very very much wants to stop things`. Not by any means. For example `SystmeException` is actually thrown when you run `sys.exit()` in the code. So if someone actually calls (mistakenly) sys.exit() in the fork, this exception is called and f we DO NOT catch BaseException the SystemException will bubble up and it will do all the atexit finalization - including all the atexit registered by the parent. This is VERY BAD because for example we could delete some files or resources that should be deleted only when the parent exits. This might lead to multiple problems. Same in case of KeyboardInterrupt or GeneratorExit. The only reason they are not part of the Exception hierarchy is that we do not want to log and handle them in catch Exception() because we always want to interrupt running appiication. But it does not mean that we want to run atexit() in the fork(). Wanting to exit immediately does not imply that we also want to run atexit() (in case of fork actually this is what we do not want). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
