Idea: changing libuv not to install a signal handler
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 25/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- linux, python
- Lĩnh vực
- backend, operating-systems
Hướng nghiên cứu
Bắt đầu bằng cách xem xét thay đổi được đề xuất trong libuv/libuv#4179 và cách uvloop hiện đang sử dụng libuv để xử lý tiến trình con và tín hiệu. So sánh hành vi đó với child watchers của Python, hỗ trợ pidfd trên Linux và các luồng chờ chuyên dụng ở những nơi khác; chỉ được xem là hoàn tất khi có thiết kế tích hợp an toàn, đã được quyết định, cùng với các kiểm thử phù hợp.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Hi,
So I've been having problems with a python-uvloop process which is run from a container and spawns child processes. If those child processes spawn their own children which lose their parents (eg. via demonize()) then there's no way to reap them (as PID1 is honour-bound to do). I had been addressing this by patching libuv to do something analagous to FastChildWatcher - ie. reap all process in SIGCHLD handler. But this isn't really safe and can interfere with other libraries or modules (eg. a synchronous process start in another python module).
In the mean time, Python itself has deprecated child-watchers and is now using pidfd on Linux, and a dedicated wait() thread in all other cases.
This means that PID-1 programs can just install their own SIGCHLD handler to reap orphaned processes.
I was wondering if my proposal over on libuv/libuv#4179 might be of interest here? The idea would be to pass a special flag to libuv to tell it not to install a signal handler, and then use the python child watchers to handle reaping of libuv spawned processes.
Without this, a python process which sets up a SIGCHLD handler is going to break if switching from asyncio to uvloop (ie. the switch is no longer transparent, as of python 3.12)
- Ngôn ngữ chính
- Cython
- Star
- 11.9k
- Fork
- 615
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Hướng dẫn đóng góp
Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của MagicStack/uvloop
-
License not clear Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
MagicStack/uvloop#759 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
MagicStack/uvloop#741 · 2 reaction ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
MagicStack/uvloop#702 · 8 bình luận · 9 reaction ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
MagicStack/uvloop#766 ·
-
Directly constructed subprocess pipe protocols segfault when callbacks use a non-process owner Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
MagicStack/uvloop#765 ·
Tất cả issue của MagicStack/uvloop
Issue tương tự
-
enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
canonical/paas-charm#368 · 1 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
tech debt
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
area:workflow bug ready-for-agent
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
fil-donadoni/tolaria#4409 ·
-
status/awaiting_triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100