Setting limits in sub-process
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 25/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
- 技術スタック
- python
調査の方向性
Start by reproducing the supplied multiprocessing fork example on AlmaLinux 8.9 with Python 3.12.3 and threadpoolctl 3.4.0, then trace the library scan through libc.dl_iterate_phdr and match_library. Compare the behavior with CentOS 7; the issue reports the scan hanging in the newer environment. Done means identifying and fixing the hang, with a regression test for the reported subprocess scenario.
索引モデルが issue の本文から書いたものです。
説明
Calling threadpool_limits in a sub-process fails (hangs) on some of my servers but fails in ones with a specific OS version:
$ hostnamectl
Static hostname: n86.my.domain
Icon name: computer-server
Chassis: server
Machine ID: 196b497eccff4526a8e34834c95e3de5
Boot ID: b8318d26cd394a85b706beb2d7324f73
Operating System: AlmaLinux 8.9 (Midnight Oncilla)
CPE OS Name: cpe:/o:almalinux:almalinux:8::baseos
Kernel: Linux 4.18.0-513.18.2.el8_9.x86_64
Architecture: x86-64
The code is:
import os
import sys
from threadpoolctl import threadpool_limits
from multiprocessing import get_context
def eprintln(text):
print(text, file=sys.stderr, flush=True)
DID_THREADCTL_FOR_PID = None
def invocation(index: int) -> int:
global DID_THREADCTL_FOR_PID
if os.getpid() != DID_THREADCTL_FOR_PID:
DID_THREADCTL_FOR_PID = os.getpid()
eprintln(f"PID: {os.getpid()} invocation index: {index} Do threadpool_limits...")
threadpool_limits(limits=1)
eprintln(f"PID: {os.getpid()} invocation index: {index} Did threadpool_limits.")
else:
eprintln(f"PID: {os.getpid()} invocation index: {index} Old threadpool_limits.")
return index
invocations = 4
processes = 2
threadpool_limits(limits=processes)
results = [None] * invocations
eprintln(f"PID: {os.getpid()} Do imap...")
with get_context("fork").Pool(2) as pool:
for index in pool.imap_unordered(invocation, range(invocations)):
results[index] = index
eprintln(f"PID: {os.getpid()} - Did imap index: {index}")
eprintln(f"PID: {os.getpid()} Did imap results: {results}")
assert results == list(range(len(results)))
When I run it on the above OS, in Python 3.12.3, threadpoolctl version 3.4.0, I get:
$ python3 bug.py
PID: 1576849 Do imap...
PID: 1576852 invocation index: 0 Do threadpool_limits...
PID: 1576853 invocation index: 1 Do threadpool_limits...
PID: 1576853 invocation index: 1 Did threadpool_limits.
PID: 1576853 invocation index: 2 Old threadpool_limits.
PID: 1576853 invocation index: 3 Old threadpool_limits.
PID: 1576849 - Did imap index: 1
PID: 1576849 - Did imap index: 2
PID: 1576849 - Did imap index: 3
And the process hangs. Poking around it seems that libc.dl_iterate_phdr does not return (each match_library_callback call does return). I am using a Python 3.12.3 that was compiled from source on this OS, followed by pip installation of numpy, pandas, scipy etc.
This same thing works fine in older versions of the OS. E.g., in:
$ hostnamectl
Static hostname: n97.my.domain
Icon name: computer-server
Chassis: server
Machine ID: 5e543d50691943628e8e20441f502406
Boot ID: 0d876250c0ec4a149e8bdb12c99c20eb
Operating System: CentOS Linux 7 (Core)
CPE OS Name: cpe:/o:centos:centos:7
Kernel: Linux 3.10.0-1160.15.2.el7.x86_64
Architecture: x86-64
With Python version 3.12.2, again with threadpoolctl version 3.4.0, I get the expected output:
$ python3 bug.py
PID: 32872 Do imap...
PID: 32874 invocation index: 0 Do threadpool_limits...
PID: 32875 invocation index: 1 Do threadpool_limits...
PID: 32874 invocation index: 0 Did threadpool_limits.
PID: 32875 invocation index: 1 Did threadpool_limits.
PID: 32874 invocation index: 2 Old threadpool_limits.
PID: 32872 - Did imap index: 0
PID: 32875 invocation index: 3 Old threadpool_limits.
PID: 32872 - Did imap index: 1
PID: 32872 - Did imap index: 2
PID: 32872 - Did imap index: 3
PID: 32872 Did imap results: [0, 1, 2, 3]
Any ideas on what I can do to fix this?
- 主要言語
- Python
- スター
- 434
- フォーク
- 38
- 平均マージ
- 2日 14時間
- マージ済み PR(30日)
- 8
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
joblib/threadpoolctl のほかの issue
-
難易度 4/5 3〜5日 初心者へのやさしさ 25/100
joblib/threadpoolctl#271 ·
メンテナーはふだん 1 日以内に返信
-
Make it possible to inspect active/spin wait behavior of LLVM/Intel OpenMP via `kmp_get_blocktime`オープン
難易度 3/5 1〜2日 初心者へのやさしさ 42/100
joblib/threadpoolctl#270 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 22/100
joblib/threadpoolctl#261 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
Opt-in API that has a cached `ThreadpoolController`対応中かも @itamarst が 27 日前に担当しました。 オープン
難易度 4/5 3〜5日 初心者へのやさしさ 25/100
joblib/threadpoolctl#254 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
Speed up usage of threadpoolctl対応中かも @itamarst が 35 日前に担当しました。 オープン
難易度 4/5 3〜5日 初心者へのやさしさ 18/100
joblib/threadpoolctl#246 ·
メンテナーはふだん 1 日以内に返信
joblib/threadpoolctl の issue をすべて見る
似ている issue
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
anchore/grype-db#1149 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
[Bug]: `hermes plugins update` clones an entire monorepo twice - `subdir` is resolved but dropped at both catalog-update call sites対応中かも @HootRock が今日担当しました。 オープンcomp/cli P2 type/perf
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
NousResearch/hermes-agent#142417 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
SMC SPEC
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
tenstorrent/tt-oca-harness#3287 ·
メンテナーはふだん 1 日以内に返信
-
bug enhancement python
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
DewaldOosthuizen/tech-cheat-sheets-and-notes#392 ·
メンテナーはふだん 1 日以内に返信
-
security
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
fabriziosalmi/wildbox#801 ·
メンテナーはふだん 1 日以内に返信