Nhánh Python nogil có sẵn trong hình ảnh Docker, vì vậy việc chạy nó chỉ là trường hợp khởi động bash trong vùng chứa đó, chạy "pip install -e '. [test]'" để cài đặt Datasette và sau đó chạy Datasette bên trong vùng chứa.
– Simon Willison [@simonw] ngày 29 tháng 4 năm 2022
Tôi KHÔNG ngờ việc này lại dễ dàng thử nghiệm như vậy. ảnh. Twitter. com/MQRHfj6HQZ
Trong cuộc chạy nước rút phát triển lõi Python hàng năm, chúng tôi đã tổ chức một cuộc họp với Sam Gross, tác giả của nogil, một nhánh của Python 3. 9 loại bỏ GIL. Đây là một bản tóm tắt phi tuyến tính của cuộc họp
tl;dr
Công việc của Sam chứng minh rằng có thể loại bỏ GIL theo cách sao cho trình thông dịch Python kết quả hoạt động hiệu quả và mở rộng quy mô với các lõi CPU được thêm vào. Để đạt hiệu quả tích cực, công việc thông dịch viên dường như không liên quan khác là bắt buộc
Hiện tại, không thể hợp nhất các thay đổi của Sam trở lại CPython vì chúng được cố tình tạo ra để chống lại di sản 3. 9 nhánh sao cho kết quả là 3. 9 Trình thông dịch nogil có thể được kiểm tra bởi người dùng cuối với cơ sở các thư viện có thể cài đặt pip và tiện ích mở rộng C hiện có. Để hợp nhất nogil, các thay đổi sẽ phải được thực hiện đối với nhánh main [hiện đang được lên kế hoạch trở thành 3. 11]
Đừng mong đợi Python 3. 11 để thả GIL chưa. Việc hợp nhất công việc của Sam trở lại CPython sẽ là một quá trình tốn nhiều công sức, nhưng chỉ là một phần của những gì cần thiết. cần có kế hoạch di chuyển và tương thích ngược rất tốt cho cộng đồng trước khi CPython bỏ GIL. Không ai trong số này được lên kế hoạch. Chúng tôi vẫn có thể quyết định nó không phù hợp
Một số người đề cập đến Python 4 khi nói về những thay đổi ở mức độ này. Các nhà phát triển cốt lõi không chủ động lên kế hoạch phát hành Python 4 vào thời điểm này, thực tế thì ngược lại. chúng tôi đang tích cực cố gắng không phát hành Python 4 vì quá trình chuyển đổi Python 2 sang 3 đã đủ khó đối với cộng đồng. Vẫn còn quá sớm để suy đoán, chứ chưa nói đến lo lắng, về Python 4
Giới thiệu về nogil
Sam đã xuất bản mã của mình cùng với một bài viết chi tiết, trong đó anh ấy giải thích động cơ và thiết kế fork của mình
Thiết kế có thể được tóm tắt như
- thay thế bộ cấp phát tích hợp sẵn của Python
pymallocbằngmimallocđể đảm bảo an toàn cho luồng, bao gồm cả sự hợp tác cần thiết để truy cập đọc không khóa vào từ điển và các bộ sưu tập khác cũng như tính hiệu quả [bố cục bộ nhớ heap cho phép tìm các đối tượng được GC theo dõi mà không cần phải duy trì một danh sách rõ ràng]; - thay thế cách đếm tham chiếu háo hức phi nguyên tử của Python bằng cách đếm tham chiếu sai lệch
- liên kết từng đối tượng với chuỗi đã tạo ra nó [được gọi là chuỗi chủ sở hữu];
- cho phép đếm tham chiếu cục bộ phi nguyên tử hiệu quả trong chuỗi chủ sở hữu;
- cho phép đếm tham chiếu chia sẻ nguyên tử nhưng chậm hơn trong các luồng khác;
- để tăng tốc độ truy cập đối tượng trên các luồng [nếu không sẽ bị chậm lại do đếm tham chiếu chia sẻ nguyên tử], hai kỹ thuật được sử dụng
- một số đối tượng đặc biệt được bất tử hóa, nghĩa là số lượng tham chiếu của chúng không bao giờ được tính toán và chúng không bao giờ được giải phóng. điều này áp dụng cho các đơn lẻ như Không, Đúng, Sai, các số nguyên nhỏ khác và các chuỗi nội bộ, cũng như các PyTypeObject được phân bổ tĩnh cho các loại tích hợp sẵn;
- đếm tham chiếu hoãn lại được sử dụng cho các đối tượng có thể truy cập toàn cầu khác như hàm cấp cao nhất, đối tượng mã và mô-đun;
- điều chỉnh trình thu gom rác theo chu kỳ để trở thành trình thu gom rác dừng thế giới đơn luồng
- đợi tất cả các luồng tạm dừng tại một điểm an toàn [bất kỳ ranh giới mã byte nào];
- không đợi các luồng bị chặn trên I/O [và sử dụng
PyEval_ReleaseThread, tương đương với việc giải phóng GIL trong Python hiện tại]; - xây dựng hiệu quả danh sách các đối tượng để phân bổ đúng lúc. nhờ sử dụng
mimalloc, tất cả các đối tượng được GC theo dõi đều được giữ trong một đống nhẹ riêng biệt;
- di chuyển bộ đệm MRO toàn cục của quy trình thành luồng cục bộ để tránh tranh chấp khi tra cứu MRO;
- sửa đổi các bộ sưu tập tích hợp để trở nên an toàn cho luồng
Tài liệu thiết kế của Sam chứa thông tin chi tiết về cách các thành phần thiết kế đó vận hành, cũng như thông tin về trạng thái luồng và API GIL, các sửa đổi mã byte và trình thông dịch khác [thay thế máy ảo ngăn xếp bằng máy ảo thanh ghi bằng thanh ghi bộ tích lũy; lệnh gọi hàm được tối ưu hóa bằng cách tránh tạo Khung ngăn xếp C; các thay đổi khác đối với ceval.c; cách sử dụng con trỏ được gắn thẻ; siêu dữ liệu an toàn theo luồng cho các mã op LOAD_ATTR, LOAD_METHOD, LOAD_GLOBAL; và hơn thế nữa]. Tôi khuyến khích bạn đọc nó trong toàn bộ
Điểm chuẩn sớm
Trình thông dịch chứng minh khái niệm không có GIL nhanh hơn 10% so với 3. 9 trên bộ điểm chuẩn pyperformance. Người ta ước tính rằng chi phí loại bỏ GIL trong trình thông dịch được sửa đổi kết hợp là khoảng 9%, hầu hết trong số đó là do đếm tham chiếu sai lệch và đếm tham chiếu bị trì hoãn. Nói cách khác, Python 3. 9 với tất cả các thay đổi khác nhưng việc loại bỏ GIL có thể nhanh hơn 19%. Tuy nhiên, điều này sẽ không khắc phục được sự cố khả năng mở rộng đa lõi
Nhân tiện, một số thay đổi đó, như tách ngăn xếp cuộc gọi C khỏi ngăn xếp cuộc gọi Python đã được triển khai cho Python 3. 11. Trên thực tế, chúng tôi có các điểm chuẩn sơ bộ so với main hiện tại chứng minh rằng các thay đổi liên quan đến hiệu suất trong Python 3. 11 làm cho nó nhanh hơn 16% so với nogil trong hiệu suất đơn luồng
Cần nhiều điểm chuẩn hơn, đặc biệt là sử dụng những gì mà Larry Hastings đã sử dụng khi điểm chuẩn Gilectomy [tại thời điểm dựa trên Python 3. 5, sau đó được chuyển sang 3. 6 chữ cái 1]
Sam nhắc chúng ta rằng một ứng dụng người dùng cuối nhất định sẽ mở rộng tốt như thế nào trên Python không có GIL thực sự phụ thuộc vào mã của người dùng cuối. Nếu không thử nghiệm nó trong tự nhiên, không thể dự đoán mã của bạn sẽ hoạt động tốt như thế nào nếu không có GIL. Do đó, không thể cung cấp một cách có trách nhiệm một con số cho biết Python không có GIL sẽ nhanh hơn gấp bao nhiêu lần
Câu hỏi cho Sam tại cuộc họp
Các câu hỏi ở đây đã được sắp xếp lại cho rõ ràng so với cách chúng xảy ra tại cuộc họp. Các câu trả lời được diễn giải từ các câu trả lời của Sam và đã được anh ấy chấp thuận khi đọc bản nháp của bản tóm tắt này. Lưu ý rằng các thành viên cốt lõi của nhóm có thể có quan điểm khác về một số chủ đề đó
Q. Mức độ rủi ro được nhận thức mà dự án nogil cuối cùng sẽ không khả thi để đưa vào CPython là gì?
Cơ sở mã như hiện tại đã chứng minh khả năng tồn tại về mặt kỹ thuật của nó. Nó hoạt động, có khả năng mở rộng và hoạt động tốt hơn cả trình thông dịch vanilla CPython và dự án Gilectomy. Gần hai năm làm việc toàn thời gian tại thời điểm này
Tất cả phụ thuộc vào mức độ cộng đồng điều chỉnh các tiện ích mở rộng C để chúng không gây ra sự cố hoàn toàn cho trình thông dịch. Sau đó, cái đuôi dài còn lại là cộng đồng áp dụng các luồng miễn phí trong các ứng dụng của họ theo cách vừa chính xác vừa có tỷ lệ tốt. Hai cái đó là thách thức lớn nhất nhưng chúng ta phải lạc quan
Q. Làm thế nào bạn sẽ đi ngược dòng công việc của bạn?
Sam hiện đang làm việc để khởi động lại công việc của mình, ban đầu được thực hiện chống lại 3. 9. 0a3, để phù hợp với 3. 9. 7 phát hành cuối cùng. Một phần của công việc này là tái cấu trúc các cam kết thành các đơn vị hợp lý để kể một câu chuyện hay hơn về những gì cần thay đổi ở đâu và tại sao
Hiện tại không có kế hoạch chuyển tác phẩm này sang main [tương lai 3. 11] chưa bởi vì nhánh đó có quá nhiều thông lượng. Ngược lại, 3. 9 có một loạt các thư viện có thể cài đặt pip được phát hành và các tiện ích mở rộng C để kiểm tra. Điều này cho phép Sam đánh giá dự án hoạt động như thế nào với mã của bên thứ ba trong thế giới thực. Việc khởi động lại trên main cần có thời gian mà lẽ ra có thể dành để cải thiện trình thông dịch GIL-free, vì vậy tại thời điểm này có lẽ còn quá sớm để tập trung vào việc cập nhật fork
Việc chia nhỏ công việc để có thể hợp nhất là có thể thực hiện được nhưng bạn phải nhớ rằng nhiều thay đổi song song mang lại hiệu suất tích cực. Trong sự cô lập, chúng là sự suy giảm hiệu suất [tạm thời?]
Lưu ý từ các nhà phát triển cốt lõi. chúng tôi không thể tích hợp các thay đổi được thực hiện đối với 3. 9 chi nhánh hiện nay. Nó có ý nghĩa cho giai đoạn này của dự án để sử dụng 3. 9 nhưng điều quan trọng là chia nó thành các phần có thể sử dụng được để có thể tích hợp từng cái một vào nhánh main. Đó là một điểm tốt khi thực hiện từng phần một có thể ảnh hưởng đến hiệu suất nhưng đó là cách tích hợp thực tế duy nhất
Q. Chúng ta có thể giải nén đăng ký VM và biên dịch mà không có các thay đổi khác không?
VM sử dụng số lượng tham chiếu hoãn lại/bất tử. Có thể chuyển đổi nó để chỉ sử dụng cách đếm tham chiếu cổ điển nhưng không rõ kết quả cuối cùng sẽ hiệu quả như thế nào [ví dụ: tất cả các đối tượng trên ngăn xếp đều sử dụng cách đếm tham chiếu hoãn lại do hiệu suất]
Q. ...và câu hỏi ngược lại. việc áp dụng nogil nếu không có máy ảo dựa trên sổ đăng ký mới sẽ khó đến mức nào?
Mặc dù VM mới chỉ cải thiện hiệu suất chứ không phải tính chính xác, nhưng nó cũng cải thiện khả năng mở rộng để cho phép Python không có GIL sử dụng các lõi có sẵn mà không cần tranh chấp. Cũng có thể sử dụng 3. 11, nhưng với một số ý tưởng từ VM dựa trên đăng ký, điều quan trọng đối với khả năng mở rộng và an toàn luồng. Nó sẽ là một khối lượng công việc đáng kể. Nhưng việc cập nhật VM dựa trên đăng ký với nhánh chính [cộng với sửa các lỗi còn lại] cũng là một khối lượng công việc đáng kể. Cả hai lựa chọn đều khả thi
Q. Đề xuất cho các tiện ích mở rộng C không mong muốn mã C của chúng được chạy song song bởi các luồng khác là gì?
Điều này sẽ mất thời gian. Mục tiêu là áp dụng gia tăng, cuối cùng là bởi phần lớn các tiện ích mở rộng C. GIL sẽ vẫn có sẵn tùy chọn dưới dạng tùy chọn thời gian khởi động trình thông dịch. Nếu nó không được bật và tiện ích mở rộng C không biết về chế độ hoạt động đó, nó có thể đưa ra cảnh báo hoặc không nhập được. Cộng đồng sẽ phải điều chỉnh các tiện ích mở rộng và chọn chúng vào chế độ không có GIL
Bằng chứng về khái niệm hiện chạy mà không cần GIL và chấp nhận bất kỳ tiện ích mở rộng C nào vì đây là những gì người dùng mong đợi khi họ tải xuống nogil. Nếu nó được áp dụng ngược dòng, sẽ hợp lý khi bắt đầu với điều ngược lại [yêu cầu Python chạy với nogil8 khi khởi động] để các thư viện bên thứ ba thích ứng. Sau đó, sau một vài bản phát hành, mặc định có thể được chuyển theo hướng ngược lại
Mặc dù sẽ không dễ dàng chuyển mọi thứ [song song rất khó], nhưng trong nhiều trường hợp, điều đó không quá khó, đặc biệt đối với các tiện ích mở rộng C bao gồm các thư viện bên ngoài
Lưu ý từ các nhà phát triển cốt lõi. có một số lượng lớn mã Python [và phần mở rộng C] "vật chất tối" không phải là mã nguồn mở. Chúng tôi cần cẩn thận để không làm hỏng nó vì người dùng của nó có thể không thực hiện được các thay đổi cần thiết hoặc báo cáo sự cố ngược dòng cho chúng tôi. Đặc biệt, một số tiện ích mở rộng C bảo vệ trạng thái bên trong của chính chúng bằng GIL. Đây là một mối lo ngại lớn và có thể là một trở ngại lớn đối với việc áp dụng Python không có GIL
Q. Bạn sẽ thêm một “khe cắm” PEP 489 mà các tiện ích mở rộng có thể sử dụng để biểu thị hỗ trợ cho nogil và không nhập được ở chế độ nogil nếu không?
Điều này đã xuất hiện rất nhiều, nó có thể là một ý tưởng hay nhưng nó không hoàn toàn rõ ràng điều đó có nghĩa là gì. Chọn tham gia chế độ GIL-free không đảm bảo rằng không có lỗi. Thay vào đó, chúng tôi có thể cho phép tất cả tiện ích mở rộng chạy theo mặc định [đây là điều đang xảy ra với nogil]. Thay vào đó, một tiện ích mở rộng không tương thích có thể sử dụng mã mô-đun main2 để chủ động hỏi trình thông dịch xem GIL có được bật hay không và đưa ra cảnh báo hoặc thậm chí là một ngoại lệ tại thời điểm nhập nếu nó không được bật.
Q. Việc kích hoạt thời gian chạy của nogil là một tùy chọn khả thi lâu dài hay một tính năng chuyển tiếp?
Lý tưởng nhất là trò chơi kết thúc là CPython không có GIL, thời gian. Tuy nhiên, dự kiến sẽ có một thời gian dài thích ứng cộng đồng. Chúng tôi muốn tránh sự rạn nứt tương tự như quá trình chuyển đổi Python 2 sang Python 3. Thay vào đó, chúng tôi muốn quá trình chuyển đổi diễn ra dễ dàng hơn, ngay cả khi điều đó có nghĩa là kéo dài quá trình chuyển đổi đó trong một khoảng thời gian dài hơn
Q. Để xác nhận, có phải trạng thái kết thúc là chỉ có nogil và không có cách nào để bật lại GIL không?
Chúng tôi vẫn chưa biết vào thời điểm này. Lý tưởng nhất là trò chơi kết thúc chỉ có một Python không có GIL nhưng không rõ liệu điều này có thể đạt được hay không
Q. Nếu các cờ tính năng này sẽ tồn tại trong một thời gian dài, điều đó có nghĩa là chúng tôi sẽ cần tăng đáng kể ma trận thử nghiệm không?
Có, bạn sẽ cần nhân đôi ma trận thử nghiệm của mình. Tuy nhiên, thử nghiệm phiên bản không có GIL có lẽ là một yếu tố dự đoán tốt về việc phiên bản GIL cổ điển có hoạt động hay không. Có thể hợp lý khi chỉ chạy thử nghiệm với GIL được bật không thường xuyên [hàng đêm?]
Lưu ý từ các nhà phát triển cốt lõi. mã thụt lùi với tốc độ vượt trội nếu không được kiểm tra. Trong CPython, chúng tôi không chạy tất cả các thử nghiệm với mọi thay đổi do thời gian chạy bắt buộc của chúng [chẳng hạn như các thử nghiệm rò rỉ tham chiếu] nhưng nếu các thử nghiệm hàng đêm cho những thay đổi đó không thành công, chúng tôi hoàn nguyên các thay đổi ngay lập tức vì việc hồi quy khác leo lên phía sau một buildbot đã bị lỗi là điều rất phổ biến
Q. Bạn nghĩ sao về việc chạy song song nhiều trình thông dịch Python với một GIL cho mỗi trình thông dịch?
Điều này theo một số cách là miễn phí, theo những cách khác cạnh tranh với đề xuất không có GIL. Có thể hỗ trợ trình thông dịch phụ trong trình thông dịch không có GIL
Không rõ liệu công việc của nhiều phiên dịch viên có được hoàn thành hay không. Với no-GIL, bạn sẽ bớt lo lắng hơn về việc chia sẻ các đối tượng giữa các luồng và bớt lo lắng hơn về khả năng tương thích của tiện ích mở rộng C vì với các trình thông dịch con, không trạng thái nào có thể thực sự là toàn cầu nữa và do đó, nó cần được cách ly cụ thể. Việc truyền các đối tượng giữa các trình thông dịch con yêu cầu một số dạng tuần tự hóa/giải tuần tự hóa cho các đối tượng có thể thay đổi. Đối với các đối tượng không thay đổi, có thể có hỗ trợ đặc biệt được thêm bởi trình thông dịch nhưng mã người dùng sẽ cần chọn các đối tượng đó nếu chúng không được biết đến là các loại nội trang không thay đổi. Điều này được thông báo bởi công việc liên quan của PyTorch sử dụng một dạng trình thông dịch phụ
Vì các trường hợp sử dụng mà Sam chủ yếu quan tâm là dữ liệu khoa học về bản chất [quy trình đào tạo PyTorch], nên khả năng chia sẻ dữ liệu trực tiếp và hiệu quả là rất quan trọng đối với hiệu suất đa luồng. Với các trình thông dịch phụ, tính năng chia sẻ như vậy chỉ có thể được bật ở cấp tiện ích mở rộng C, đẩy nhiều mã hơn tới C/C++ so với Python không có GIL
Q. Bạn đã đi sâu vào chi tiết về việc triển khai dict và list. Còn các loại có thể thay đổi khác như hàng đợi, bộ, mảng, v.v. thì sao?
Phân nhánh nogil là một công việc đang được tiến hành. Việc triển khai dict và list đã thấy nhiều công việc nhất do sự phổ biến của chúng trong hoạt động bên trong của trình thông dịch. Công việc tương tự đã hoàn thành liên quan đến hàng đợi nhưng chưa hoàn thành. Bộ là bộ lớn tiếp theo để trang trải
Hàng đợi rất quan trọng vì nó được sử dụng để liên lạc giữa các luồng với main6 và main7. Hàng đợi dễ dàng hơn từ điển và danh sách, họ đã sử dụng khóa chi tiết thay vì đọc không khóa. Một số đối tượng khác có thể sẽ cần sự kết hợp
Công việc này rất khó thực hiện vì bạn cần cẩn thận khi lấy và mở khóa, ví dụ: Py_DECREFs có thể được cấp lại. Vẫn có thể xem xét thêm các khóa “thô chi tiết” cho những khóa đó nhưng tất nhiên những khóa đó có nguy cơ bế tắc
Q. nogil phụ thuộc như thế nào vào mimalloc?
mimalloc không chỉ được sử dụng cho mục đích an toàn của luồng. Sự hợp tác của nó là cần thiết để kích hoạt từ điển đọc không khóa, nó cũng cho phép theo dõi GC hiệu quả
Người bảo trì của mimalloc quan tâm đến việc hỗ trợ CPython một cách rõ ràng và sẵn sàng chấp nhận những thay đổi cần thiết để thực hiện điều đó
Các triển khai nogil1 khác được báo cáo là ổn định với CPython. nogil2 được sử dụng tại Facebook, nogil3 được sử dụng tại Google, mặc dù ít tích hợp hơn, giống như các thay thế đơn giản của trình phân bổ mặc định
Lưu ý từ các nhà phát triển cốt lõi. Christian Heimes và Pablo Galindo Salgado đang đánh giá bằng cách sử dụng mimalloc cho CPython. Các thử nghiệm ban đầu cho thấy trung bình không có hồi quy hiệu suất [trung bình hình học], với hầu hết các điểm chuẩn hoạt động tốt hơn và một số lượng nhỏ các điểm chuẩn hoạt động kém hơn một chút. Có những vấn đề có thể để đánh giá
- Tính ổn định của API và ABI của
mimalloc; - cấp phép
- tính di động trên tất cả các nền tảng được CPython hỗ trợ, ví dụ:
nogil6 chỉ khả dụng trong C11; - tích hợp với các công cụ định hình và khử trùng [Valgrind, asan, ubsan, v.v. ];
- và có thể nhiều hơn nữa
Q. Dự án của bạn có những điểm tương đồng nào với Larry's Gilectomy?
Ở cấp độ cao, dự án tương tự. đếm tham chiếu bị trì hoãn, khóa chi tiết, những thách thức xung quanh việc trả lại các tham chiếu đã mượn. Không có tái sử dụng mã với Gilectomy
Q. Bạn đang nói rằng công việc của bạn ở cấp độ cao tương tự như Larry's Gilectomy. Công việc của ông cũng dựa trên việc đếm tham chiếu hoãn lại. Tuy nhiên, anh ấy chỉ quan sát thấy sự suy giảm hiệu suất trong Gilectomy. "Nogil" của bạn có một hồ sơ hiệu suất đầy hứa hẹn. Bạn nghĩ sự khác biệt đến từ đâu?
Việc chuyển sang trình biên dịch dựa trên thanh ghi và các tối ưu hóa khác đã được thực hiện, chẳng hạn như từ điển không khóa đọc được cung cấp bởi mimalloc và tránh tranh chấp với việc đếm tham chiếu bị trì hoãn, là rất quan trọng để tạo thang đo nogil và hoạt động tốt. Ngoài ra, trong một số trường hợp, chính Python đã phát triển nhanh hơn. Ví dụ: các lệnh gọi hàm trong Python 3. 9 rẻ hơn nhiều so với trong Python 3. 5
Làm cho nó mở rộng quy mô chắc chắn mất nhiều công sức hơn dự kiến
Q. Có thể chọn tiện ích mở rộng C vào chế độ không có GIL hoặc chọn không tham gia không?
Đúng như tên gọi, GIL là một khóa toàn cầu đơn giản. Để nó bảo vệ bất kỳ phần dữ liệu được chia sẻ nào, nó cần được bật trên tất cả các luồng, không chỉ trong một luồng có tiện ích mở rộng không tương thích
Thật khó để chuyển trình thông dịch từ không có GIL sang chạy với GIL [và ngược lại] trong một quy trình đã chạy. Điều có nhiều khả năng là một công tắc thời gian khởi động kích hoạt GIL hoặc không bên trong quy trình. Tiện ích mở rộng C không được gắn thẻ là tương thích sẽ đưa ra cảnh báo hoặc không nhập được
Ngoài ra, sẽ khả thi khi luôn "dừng thế giới" khi tiện ích mở rộng C được truy cập nhưng điều này đánh bại mục đích loại bỏ GIL hiệu suất khôn ngoan
Lưu ý từ các nhà phát triển cốt lõi. có một vài ý tưởng khác cho đến nay vẫn chưa được khám phá sâu. Một là chuyển đổi GIL thành khóa “nhiều người đọc - một người viết”. Trong trường hợp này, chế độ không có GIL về cơ bản sẽ lấy khóa dưới dạng “trình đọc”, e. g. mà không chặn mã mới khác làm điều tương tự. Mã kế thừa sẽ có khóa "người viết", chặn tất cả các luồng khác thực thi cho đến khi được giải phóng. Thiết kế này sẽ yêu cầu giữ các API thu thập/phát hành GIL mà nogil đã thực hiện để thông báo cho GC rằng một luồng bị chặn trên I/O
Q. Có thể đánh dấu các chức năng là không an toàn cho luồng không [e. g. sử dụng một trình trang trí] và có tính đến điều này khi nogil chạy mã để ngăn các luồng khác cản trở không?
Nếu mối quan tâm là về trạng thái được truy cập ở nơi khác, thì mọi quyền truy cập cần phải bị khóa. Điều này đặc biệt không khả thi ở cấp độ trang trí. Việc kích hoạt GIL có điều kiện cho các đường dẫn bao gồm mã không an toàn sẽ khó thực hiện, như đã đề cập ở trên
Q. Tự khóa thay vì dựa vào GIL có thể khó. Bạn có mong đợi sự gia tăng các vấn đề liên quan đến chủ đề với nogil không?
Không rõ. Đối với tiện ích mở rộng API C, có ít nhất một mẫu thiết kế tốt. chúng thường có cấu trúc tương tự nhau và giữ trạng thái chia sẻ trong một cấu trúc duy nhất. pymalloc2 có vẻ xa nhất so với mẫu này vào thời điểm này nên hầu hết các thay đổi có thể được yêu cầu trong các phần mở rộng C được viết bằng nó
Nhiều tiện ích mở rộng C phức tạp đã phải xử lý việc khóa và đa luồng vì lý do tồn tại của chúng là giải phóng GIL càng nhiều càng tốt, chẳng hạn như pymalloc3 chẳng hạn. Vì vậy, có lẽ đáng ngạc nhiên, những thứ đó có thể dễ dàng di chuyển hơn
Bước tiếp theo
Tiếp theo cuộc họp này, các nhà phát triển cốt lõi đã thảo luận về tính khả thi của việc bao gồm nogil ngược dòng và điều đó có ý nghĩa gì đối với cộng đồng. Chắc chắn, một sự thay đổi tầm cỡ này cần rất nhiều sự quan tâm
Trước khi chúng tôi quyết định điều đó, sẽ khả thi hơn nếu giới thiệu một số mã của nó trước. Đặc biệt, mimalloc có vẻ thú vị và đã có một yêu cầu kéo mở đang khám phá sự bao gồm của nó. Tìm kiếm các liên kết đến điểm chuẩn
Ở cấp độ cá nhân, chúng tôi rất ấn tượng với công việc của Sam cho đến nay và mời anh ấy tham gia dự án CPython. Tôi vui mừng thông báo rằng anh ấy quan tâm và để giúp anh ấy phát triển trở thành nhà phát triển cốt lõi, tôi sẽ cố vấn cho anh ấy. Guy và Neil Schemenauer sẽ giúp tôi xem lại mã cho các bit phiên dịch mà tôi không quen thuộc