Ý định phê duyệt PEP 703 để biến GIL của CPython thành tùy chọn
(discuss.python.org)- Python Steering Council đang có ý định chấp nhận PEP 703 để biến GIL thành tùy chọn trong CPython, và phản ứng của cộng đồng đối với cả đề xuất no-GIL lẫn PEP 703 nhìn chung cũng khá tích cực
- Mục tiêu dài hạn là hợp nhất về bản dựng no-GIL, đồng thời tránh tình huống hệ sinh thái bản dựng with-GIL và no-GIL cũng như các extension module bị chia tách vĩnh viễn
- Trong quá trình chuyển đổi, tính tương thích ngược là ràng buộc cốt lõi; ngay cả mã bên thứ ba được thay đổi để hỗ trợ no-GIL cũng phải tiếp tục hoạt động trên bản dựng with-GIL
- Kế hoạch là chuyển đổi 3 giai đoạn gồm bản dựng thử nghiệm ngắn hạn, bản dựng được hỗ trợ ở trung hạn và bản dựng mặc định ở dài hạn; bản dựng thử nghiệm có thể xuất hiện trong Python 3.13, nhưng nếu lùi sang 3.14 cũng không bị xem là vấn đề
- Trước khi chuyển sang bản dựng mặc định, cần xác nhận sự hỗ trợ của cộng đồng cũng như trải nghiệm API, đóng gói và phân phối; nếu mức độ hỗn loạn lớn hơn lợi ích thì phải có thể dừng PEP 703 và tìm giải pháp khác
Định hướng tiếp nhận PEP 703 của Steering Council
- Python Steering Council có ý định chấp nhận PEP 703
- Trong khảo sát về đề xuất no-GIL, phản hồi nhìn chung là tích cực, và Steering Council cũng nhìn chung có quan điểm tích cực với cả ý tưởng tổng thể lẫn PEP 703
- Tuy vậy, các chi tiết của việc chấp nhận vẫn đang được hoàn thiện và dự kiến sẽ được chốt trong vài tuần tới
Nguyên tắc chuyển đổi để tránh phân nhánh vĩnh viễn
- Về dài hạn, có lẽ trong khoảng thời gian trên 5 năm, bản dựng no-GIL sẽ phải trở thành bản dựng duy nhất
- Họ không muốn tình huống bản dựng with-GIL và no-GIL bị tách biệt vĩnh viễn
- Họ cũng muốn tránh việc hệ sinh thái extension module bị chia tách lâu dài theo hai bản dựng
- Tính tương thích ngược phải được xử lý hết sức thận trọng
- Họ không muốn tạo ra thêm một kịch bản chuyển đổi kiểu Python 3 nữa
- Dù mã bên thứ ba có thay đổi để hỗ trợ bản dựng no-GIL, những thay đổi đó vẫn phải hoạt động trên bản dựng with-GIL
- Các vấn đề tương thích ngược với những phiên bản Python cũ hơn cần được xử lý riêng
- Đây không phải Python 4
- Các yêu cầu về tương thích ABI, chi tiết của hai bản dựng và tác động đến tính tương thích ngược vẫn đang được xem xét
Các điều kiện cần xác nhận trước khi đổi mặc định
- Trước khi chuyển bản dựng no-GIL thành mặc định, cần xác nhận rằng sự hỗ trợ từ cộng đồng đã đủ hay chưa
- Không thể chỉ đổi mặc định rồi để cộng đồng tự tìm xem mình cần phải làm gì
- Các core developer cần trực tiếp trải nghiệm chế độ bản dựng mới và những thành phần xung quanh nó
- Trong quá trình làm rõ tính an toàn luồng của mã hiện có, có thể sẽ cần C API và Python API mới
- Những hiểu biết thu được trong quá trình đó cần được chia sẻ với cộng đồng Python
- Cần xác nhận rằng các thay đổi mà core developer mong muốn và các thay đổi họ yêu cầu cộng đồng thực hiện đều ở mức chấp nhận được
- Cho đến trước khi no-GIL trở thành mặc định, nếu đánh giá rằng thay đổi gây ra quá nhiều hỗn loạn trong khi lợi ích lại nhỏ, thì cần có khả năng đổi hướng
- Trong trường hợp đó, cũng phải có khả năng đưa ra quyết định hoàn tác toàn bộ công việc
- Vì vậy, mã chỉ dành cho no-GIL cần phải có thể nhận diện được ở một mức độ nào đó
Kế hoạch chuyển đổi 3 giai đoạn
- Trong ngắn hạn, sẽ thêm bản dựng no-GIL như một chế độ bản dựng thử nghiệm
- Có thể sẽ xuất hiện trong Python 3.13
- Nếu lùi sang Python 3.14 cũng không bị xem là vấn đề
- Trạng thái thử nghiệm nhằm làm rõ rằng các core developer ủng hộ chế độ bản dựng này, nhưng không có nghĩa cộng đồng phải ngay lập tức hỗ trợ nó
- Cần thời gian để có thể xây dựng sự hỗ trợ từ cộng đồng ở các khía cạnh thiết kế API, đóng gói và phân phối
- Không khuyến nghị các bản phân phối cung cấp bản dựng no-GIL thử nghiệm làm trình thông dịch mặc định
- Trong trung hạn, bản dựng no-GIL sẽ trở thành đối tượng được hỗ trợ nhưng vẫn chưa là mặc định
- Cần có sự tin tưởng rằng mức hỗ trợ từ cộng đồng đã đủ để dùng trong production
- Ở giai đoạn này sẽ xác định ngày mục tiêu hoặc phiên bản Python mục tiêu để biến no-GIL thành mặc định
- Thời điểm này phụ thuộc lớn vào tính tương thích ngược của thay đổi API, cách xử lý stable ABI và khối lượng công việc mà cộng đồng cho là cần thiết
- Có thể mất ít nhất 1–2 năm, hoặc lâu hơn
- Khi được tuyên bố là đối tượng hỗ trợ, một số nhà phân phối có thể bắt đầu cung cấp no-GIL làm mặc định, nhưng điều này cũng có thể phụ thuộc vào số lượng package Python hỗ trợ no-GIL tại thời điểm đó
- Trong dài hạn, mục tiêu là biến no-GIL thành mặc định và loại bỏ các dấu vết của GIL
- Sẽ không phá vỡ tính tương thích ngược một cách không cần thiết
- Nếu duy trì lâu dài hai chế độ bản dựng phổ biến, gánh nặng cho cộng đồng có thể tăng lên, chẳng hạn tài nguyên kiểm thử và các kịch bản gỡ lỗi sẽ tăng gấp đôi
- Tuy vậy cũng không thể vội vàng, và có thể mất tối đa 5 năm để đi đến giai đoạn này
Đánh giá lại liên tục và khả năng dừng lại
- Trong toàn bộ quá trình, không chỉ Steering Council mà cả các core developer cũng cần liên tục đánh giá lại tiến độ và lịch trình được đề xuất
- Họ không muốn công việc này biến thành thêm một cuộc chiến tương thích ngược kéo dài 10 năm nữa
- Nếu PEP 703 có dấu hiệu trở thành vấn đề, cần phải có khả năng dừng lại và tìm giải pháp khác
- Cần thường xuyên xác nhận rằng công việc tiếp diễn vẫn xứng đáng với công sức bỏ ra
1 bình luận
Các ý kiến trên Hacker News
Trong nhiều thập kỷ, rất nhiều mã thư viện C đã có cảnh báo trong tài liệu rằng chúng không ổn định trong các ngữ cảnh bất đồng bộ, tái nhập hoặc đệ quy.
Dù vậy, chúng ta đã học được cách xử lý, và các phiên bản an toàn khi tái nhập dần dần được phát hành mà không làm API trở nên quá bất ổn.
Có những thứ như phân tích chuỗi bằng cách token hóa tại chỗ, các lời gọi DNS dùng bộ đệm tĩnh, hay mã dựa vào hành vi stack đặc thù của Vax; theo tôi, GIL vừa là phước lành vừa là lời nguyền.
Nhờ đó, tôi có thói quen kiểm tra tài liệu ngay cả với những API mình biết ở mức nào đó, phòng khi đã bỏ sót chi tiết quan trọng nào hoặc có gì thay đổi.
Khi đó tôi đang làm C++ đa nền tảng, và Java lần đầu tôi thấy đã có sẵn ngay từ đầu các tính năng như concurrency, garbage collection và nhiều thứ dễ dùng hơn C++; tôi tin chắc nó sẽ bùng nổ.
Sau đó các lập trình viên dòng chính bắt đầu dùng Python; theo tôi nhớ thì ban đầu nó là một ngôn ngữ mở rộng có thể nhúng, nên đơn giản, và vì thế GIL cũng hợp lý hơn.
Không phải ai đó bật một công tắc rồi làm vỡ một loạt mã C đáng ngờ cùng một lúc.
Giờ đã có cả CPU 128 nhân, và CPU giá rẻ cũng có 6 nhân, nên ràng buộc bị giới hạn bởi hiệu năng đơn nhân sẽ ngày càng trở thành hạn chế lớn hơn.
Lúc đầu tôi tin đó là vấn đề sẽ được giải quyết trong vài tuần, lâu lắm là vài tháng; hóa ra khi ấy tôi còn quá thiếu hiểu biết.
Trong C, tương tác với các hàm không an toàn luồng trực tiếp hơn nhiều, và khi viết C thì hầu hết mọi người cũng cẩn thận hơn.
Python có cả những module C mang trạng thái toàn cục; sau khi tải chừng 10 module như vậy, cộng thêm độ phức tạp của interpreter, chẳng mấy chốc sẽ không ai biết chuyện gì đang xảy ra nữa.
Ngay cả hiện nay, đa số lập trình viên, thậm chí cả các core developer, cũng không kiểm tra rò rỉ bộ nhớ; tôi không nghĩ họ sẽ chạy tsan, và ngay cả nếu có thì có khả năng đó chỉ là một bộ test nhỏ bao phủ khoảng 10% mã.
Nhìn vào thực hành phát triển phần mềm trong Python, đặc biệt ở mảng AI, tôi rất bi quan về tính năng này.
Cũng thú vị đấy.
Python phần lớn được cấu thành từ các thư viện chia sẻ C được viết với hiểu biết rằng chúng có thể dựa vào khóa toàn cục.
Một số đủ đơn giản để có thể chạy tốt mà không cần khóa, nhưng số khác vẫn cần khóa và giờ sẽ chịu áp lực phải chạy mà không có GIL.
Một phần trong số đó sẽ tự triển khai khóa trong phạm vi của mình; có lẽ điều Python thật sự còn thiếu chính là các lời gọi mutex tạm bợ rải rác khắp hệ sinh thái.
Tôi không ngờ Python sẽ bị phá hỏng theo cách đưa data race và deadlock vào với lý do hiệu năng.
Làm cho một thư viện C vốn được viết với giả định có khóa toàn cục trở nên thread-safe là việc ngay cả chuyên gia concurrency cũng khuyên nên tránh, và là loại công việc rất dễ mắc sai lầm khi triển khai.
Giả thuyết của tôi là đa số người viết Python C extension không phải chuyên gia concurrency, mà là những lập trình viên giỏi không ngại thử thách; với tổ hợp này thì data race/treo/segfault gần như là điều tất yếu.
Nhưng kỳ vọng 5 năm sau sẽ đổi sang opt-in là quá lạc quan.
Mọi nhà phát triển thư viện đều phải sửa thư viện của mình, cả các thư viện Python nữa; đó là việc khó, và dù làm tốt thì cũng khó được ghi nhận vì chẳng ai nhận ra.
Cũng có nhiều thư viện hoàn toàn không có use case đa xử lý, còn các thư viện lớn thì gần như chắc chắn sẽ phát sinh lỗi tinh vi, dẫn đến những phàn nàn không tái hiện được và việc nhà phát triển bỏ cuộc như một kết quả được đảm bảo.
Python có GIL vẫn hỗ trợ thread, nên các thư viện như vậy ít nhất cũng phải an toàn khi tái nhập.
Nếu một thư viện có thể tái nhập nhưng không thread-safe, có thể chỉ cần thêm một khóa toàn cục bao quanh mọi lời gọi là đủ, và việc này khá giống với điều GIL từng làm.
Trong nhiều trường hợp, làm cho thư viện hiện có hoạt động không cần GIL có vẻ tương đối thẳng tiến, dù có thể phải hy sinh tính song song.
Vấn đề cốt lõi có lẽ là các thư viện gọi callback từ phía C về Python runtime.
Câu hỏi hơi ngây thơ, nhưng đã có các gói asyncio và multiprocessing rồi thì ai cần No-GIL nữa?
Tôi chưa từng gặp vấn đề vì GIL trong Python; luôn né được bằng cách mở ThreadPool hoặc ProcessPool, hoặc dùng thư viện bất đồng bộ khi cần
Tôi tò mò liệu có use case No-GIL nào mà multiprocessing không giải quyết được không
Tôi từng nghĩ thực thi đơn luồng không có overhead của các primitive đồng thời là tốt nhất cho điện toán hiệu năng cao, như LMAX Disruptor đã cho thấy
asyncio về bản chất là đơn luồng nên chỉ dùng một core, còn multiprocessing dùng đa core nên tốt hơn về hiệu năng, nhưng mỗi process tương đối nặng và có thêm overhead bộ nhớ chia sẻ
Đa luồng dựa trên GIL thì chỉ dùng một core và cũng khó viết đúng
Đa luồng No-GIL dùng đa core nhưng khó sử dụng; tôi không rõ phần triển khai, nhưng bộ nhớ chia sẻ lẽ ra phải nhanh hơn multiprocessing
Nếu thiết kế một hệ thống mới, tôi đồng ý rằng với gần như mọi use case Python thì nên tránh đụng đến thread và dùng asyncio/multiprocessing
Các chương trình Python cần đa luồng nhanh thường lẽ ra không nên được viết bằng Python ngay từ đầu, nhưng vì đã có những người viết code CPU-intensive bằng Python rồi nên No-GIL là thực dụng
Giả sử có một web server dùng trạng thái chia sẻ để phản hồi đồng thời nhiều client; multiprocessing dùng pickle khi truyền dữ liệu qua lại nên overhead hiệu năng rất lớn
Ví dụ, nếu bạn có một cấu trúc dữ liệu 1GB trong bộ nhớ và muốn tính toán song song, multiprocessing khó xử lý với hiệu năng tốt
Dùng pickle thì không thể chia sẻ mọi object, và lỗi object không pickle được rất khó debug trong các cấu trúc dữ liệu phức tạp
Đặc biệt, các object do thư viện native tạo ra có thể không chia sẻ được
Các xử lý cần chia sẻ trạng thái khi đang chạy cũng rất khó làm bằng module multiprocessing; ngay cả Prometheus exporter cho Flask cũng cần một hack kỳ quặc dùng thư mục tạm để gom thống kê từ mọi process
Ông nói trong nhiều ứng dụng của DeepMind, họ muốn chạy khoảng 50–100 thread cho mỗi process, nhưng thường GIL đã trở thành nút thắt ngay cả khi chưa tới 10 thread
Họ cũng dùng subprocess như một cách né tránh, nhưng trong nhiều trường hợp overhead giao tiếp liên tiến trình trở nên quá lớn, rốt cuộc buộc phải chuyển phần lớn codebase Python sang C++
Với mức sử dụng trung bình như web app, multiprocessing có thể là đủ, nhưng trong các workload AI quy mô lớn như ở Google và DeepMind, GIL thực sự hạn chế việc dùng Python
Đây cũng là lý do Meta muốn bỏ ra 3 năm kỹ sư cho công việc này: https://news.ycombinator.com/item?id=36643670
Đúng như tên gọi, nó chỉ thật sự hữu ích với các vấn đề I/O-bound
Chia sẻ dữ liệu giữa nhiều process là cực kỳ khổ sở, và vừa kiểm soát dữ liệu vừa orchestration process còn khổ hơn nữa
Process thì đắt, và do khó khăn trong chia sẻ dữ liệu như đã nói ở trên, greenlet cũng khó trở thành một lựa chọn thay thế thực sự
Nhưng trong các lĩnh vực nơi Python chiếm tỷ trọng lớn như AI và khoa học dữ liệu, khả năng chạy hàng loạt thread CPU/GPU-bound là một lợi thế lớn
Nhiều C extension được viết mà không tính đến đa luồng, nên có thể sẽ phát sinh vấn đề, và thực tế tôi nghĩ là sẽ như vậy
Đây là một ví dụ nhỏ không an toàn nếu
lstcó thể bị truy cập từ thread khác: https://news.ycombinator.com/item?id=36649769Ngay cả hiện nay, nếu code C callback vào bytecode Python thông qua phương thức
__del__và bytecode đó đủ dài, có lẽ khoảng 100 lệnh là có thể xảy ra chuyển ngữ cảnhTuy nhiên đó là trường hợp cực hiếm, và nhiều code C extension không được viết với tình huống này trong đầu
Người dùng C extension cũng có thể đang phụ thuộc vào việc chúng được thực thi một cách nguyên tử
Ví dụ, cách đưa vào và lấy ra mảng numpy trong thread pool hiện hoạt động tốt, nhưng khi không có GIL thì có thể bị hỏng
Vì vậy đề xuất và hướng làm việc là giữ chế độ non-GIL hoàn toàn tùy chọn, không đặt làm mặc định
Một số ít người can đảm bật nó lên dùng sẽ phải chuẩn bị tinh thần bỏ ra rất nhiều thời gian để tìm và sửa các race condition tinh vi trong code thư viện Python đã tồn tại hàng chục năm
Những người áp dụng sớm sẽ chịu nhiều đau đớn, hoặc nhiều khả năng hơn là chỉ giới hạn non-GIL trong các process chuyên biệt rất đặc thù với dependency được giảm tối đa
Ta đang chuyển từ trạng thái nghi ngờ là có vấn đề sang trạng thái biết chính xác vấn đề nằm ở đâu, rồi phần còn lại là lần lượt cắt giảm danh sách đó
Có thể thêm một dạng mutex nào đó quanh code, hoặc đổi sang triển khai thay thế không phải native code và ít gây vấn đề hơn
Lập luận phản đối chủ yếu là việc này rất nhiều việc, chứ có vẻ không phải là bất khả thi
Nếu có đủ người làm, kết quả có thể đạt được
Nếu không, họ đã công bố kế hoạch đột ngột loại bỏ toàn bộ GIL thay vì cách tiếp cận theo từng bước để người dùng tự chọn chế độ No-GIL
Hãy nhớ lại các cuộc chuyển đổi từ văn bản sang Unicode, từ 32-bit sang 64-bit, từ Intel sang ARM, hay Y2K là đủ
No-GIL là một thay đổi nhỏ hơn nhiều, và có thể đi theo cùng lộ trình chuyển đổi mà không phá vỡ mọi thứ một cách cực đoan
Dù có thứ gì bị hỏng, cũng sẽ có một cách được định nghĩa rõ ràng để xử lý các trường hợp đó
Dù sao thì chúng ta cũng đã sống sót qua những cuộc chuyển đổi ấy, và thật vui khi thấy mọi thứ tiến lên
Nó sẽ mở ra thêm nhiều lĩnh vực vốn đến nay vẫn bị gắn nhãn là bất khả thi
Một trong những điều Swift thời kỳ đầu làm tốt là đưa các thay đổi phá vỡ tương thích vào lời hứa của mình, và mọi người đều biết vị trí của mình rồi thích nghi tốt
Đôi khi tôi cũng mong Python đi theo con đường tương tự
Từ 32-bit sang 64-bit, sang ARM, rồi Y2K đều có thể kiểm thử xem có hoạt động hay không
Tất nhiên kiểm thử có thể không bao phủ các ca lỗi, nhưng các kiểm thử đã chạy là mang tính xác định
Nhưng ở đây, dù kiểm thử bao nhiêu đi nữa, câu trả lời vẫn là “đúng, hoặc là vẫn chưa chạm đúng race condition phù hợp”
Dù có nói rõ rằng họ không muốn lặp lại kịch bản chuyển đổi Python 3, cách tiếp cận hiện tại vẫn trông gần với con đường đó đến rợn người
Rất nhiều thứ phụ thuộc vào cộng đồng Python và các kênh phân phối
Cộng đồng có thể không áp dụng kịp thời, hoặc các bản phân phối như Ubuntu, Fedora, Anaconda có thể vội vàng đi trước
Còn quá sớm để khẳng định, nhưng tôi tự hỏi Steering Council thực sự có bao nhiêu quyền kiểm soát để tránh kịch bản này
5 năm là quá lâu để Python có hai chế độ
Nửa thập kỷ là đủ để hai chế độ đông cứng thành hiện trạng, và sau đó các bài viết Stack Overflow cũ vẫn sẽ còn đó
Tôi không lạc quan rằng 5 năm sẽ không kéo dài thành 10 năm bất định và hỏng hóc
Ngược lại, 5 năm cũng có thể là quá ngắn để lôi toàn bộ mã C ra sửa, kiểm thử và gọi là đã trưởng thành
Các công ty đã hứa hỗ trợ có thể chuyển đổi một số dự án bằng máy móc, rồi quấy rầy các nhà phát triển thực sự hoặc đe dọa fork
Các lỗi sẽ được những nhà phát triển không lương thực sự mài giũa trong nhiều năm
Nhưng Python cần một “thành công” nào đó, và đây là một câu chữ PR hay
Trong thế giới Python, có vẻ độ chính xác không quan trọng lắm
Vì lịch sử đó, nghe như họ muốn duy trì hai chế độ thực thi bên trong CPython 3 hơn là tiến tới một cuộc chuyển đổi major khác
Thật may là họ rất ý thức rằng chuyện này có thể dễ dàng trở thành thảm họa Python 4
Cần cực kỳ cẩn trọng để không vô tình ảnh hưởng đến hành vi yes-GIL
Nếu một dạng GIL mô phỏng nào đó không hoàn toàn giống GIL thật, đủ kiểu trường hợp kỳ lạ có thể xảy ra
Thứ nhất, họ không muốn nó như vậy
Thứ hai, nếu nó thành ra như vậy thì họ sẽ từ bỏ nhanh
Cả hai đều quan trọng, nhưng dường như còn thiếu mảnh ghép quan trọng thứ ba: “và đây là cách chúng tôi sẽ đạt được điều đó”
Họ đã nói rằng GIL và No-GIL có thể cùng tồn tại hơn 5 năm
Với người làm công cụ, điều đó có nghĩa là chi phí sẽ tăng gấp đôi trong ít nhất 5 năm tới
Vì dù là dùng cho sản xuất hay thử nghiệm, mọi người sẽ muốn dùng công cụ ở cả hai chế độ
GIL là Global Interpreter Lock
Có phần giải thích hay ở đây: https://realpython.com/python-gil/
Ở đây có hai vấn đề lớn
Thứ nhất, một số cải tiến đáng để phá vỡ tương thích ngược và loại bỏ GIL là một cải tiến như vậy
Việc các thay đổi của Python 3 có đáng như vậy hay không còn gây tranh cãi, và việc
printtrở thành hàm thì trông không đặc biệt đáng giáTuy nhiên, quá trình chuyển đổi 2-to-3 phần nào đã bị một thiểu số ồn ào thổi phồng, và theo kinh nghiệm của tôi khi chuyển hơn 5 codebase từ 2 sang 3, đa số gặp ít vấn đề
Vấn đề lớn nhất là những codebase bị các nhà phát triển trước đó kéo thư viện vào cho mọi thứ, biến thành một đống thư viện bị bỏ mặc; loại mã như vậy sẽ gặp vấn đề ngay cả khi ngôn ngữ lõi không phá vỡ tương thích
Câu trả lời không phải là gây áp lực để ngôn ngữ vĩnh viễn không được phá vỡ tương thích, mà là đừng kỳ vọng rằng kéo cả pip về sẽ là một chiến lược bền vững
Hiện tại Steering Council đã bị thiểu số ồn ào chỉ trích quá nhiều đến mức sợ các thay đổi phá vỡ tương thích
Nhưng việc loại bỏ GIL là một phần quá nền tảng trong cách Python hoạt động nên nó phải là một thay đổi phá vỡ tương thích; tốt hơn là thừa nhận điều đó và lập kế hoạch chuyển đổi, thay vì vì sợ người dùng mà không dám thừa nhận sự thật rồi cố làm điều bất khả thi là khiến nó không phá vỡ
Python 3.11 cũng đã làm hỏng codebase của tôi, và việc sửa không khó, nhưng tôi ước họ truyền thông tốt hơn rằng chuyện như vậy có thể xảy ra
Thứ hai, vấn đề mang tính nền tảng hơn là nhiều tính năng khác của Python được xây dựng xoay quanh GIL
Đặc biệt mô hình bất đồng bộ có nhiều ý nghĩa vì GIL; nếu không có GIL, nhìn lại thì mô hình actor kiểu send/recv của Erlang hẳn đã là hướng đi tốt hơn nhiều
Điều này khó đảo ngược, và tôi có cảm giác Python đang bị đẩy thành một tập hợp kém gắn kết hơn gồm các tính năng không thật sự ăn khớp với nhau, nên có vẻ như quá ít và quá muộn
Cảm ơn các nhà phát triển nòng cốt của Python và Steering Council; Python là một trong những ngôn ngữ tôi yêu thích, cùng với Java và C
Tôi rất hoan nghênh đa luồng thực sự trong Python
Tùy dự án, tôi dùng cả multiprocessing lẫn multithreading; ví dụ về multiprocessing có ở [0], còn ví dụ dùng Python Threads cho các tác vụ nhiều I/O có ở [1]
Nhưng dùng luồng thật sự hẳn sẽ hiệu quả hơn nhiều
Luồng có thể trao đổi một lượng dữ liệu tùy ý trong một thao tác nguyên tử đơn lẻ và gần như tức thì, nhưng giao diện loopback cục bộ, multiprocessing hay pipe thì không làm được
Tôi đang làm việc trên một kiến trúc đa luồng mà tôi gọi là “three tier multithreading architecture”
https://github.com/samsquire/three-tier-multithreaded-archit...
Mục tiêu là một máy chủ có khả năng mở rộng cực cao và hiệu năng tốt, nhưng có lẽ Python không phải là công cụ phù hợp cho việc đó
[0]: https://news.ycombinator.com/item?id=36897054 giải thích cách dùng multiprocessing
[1]: https://devops-pipeline.com/ ví dụ dùng multithreading