westonpace commented on a change in pull request #12358:
URL: https://github.com/apache/arrow/pull/12358#discussion_r801202506
##########
File path: cpp/src/arrow/util/mutex.cc
##########
@@ -50,5 +55,31 @@ Mutex::Guard Mutex::Lock() {
Mutex::Mutex() : impl_(new Impl, [](Impl* impl) { delete impl; }) {}
+#ifndef _WIN32
+namespace {
+
+struct AfterForkState {
+ // A global instance that will also register the atfork handler when
+ // constructed.
+ static AfterForkState instance;
+
+ // The mutex may be used at shutdown, so make it eternal.
+ // The leak (only in child processes) is a small price to pay for robustness.
+ Mutex* mutex = nullptr;
Review comment:
> Maybe it's not trivial when working with multiprocessing in Python
Do you have a particular use case in mind? For example, the most common
multiprocessing pattern is "fork-join" where you fork off a number of child
processes for some task and then join them all back together when the task is
done. In that case the leak would be limited because the memory would be free
when the child process ended.
The only way to really grow this leak is to recursively and continuously
fork. Even then you would run out of process IDs far before any significant
memory was lost. I suppose you could be continuously killing the parent off
after the fork and leaving an orphan but I don't know of any real world use
case for this.
--
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]
