Komuniti Python sedang giat membincangkan peralihan berpotensi daripada corak async/await ke arah virtual threads, didorong oleh kekecewaan yang semakin meningkat terhadap kerumitan model konkurensi semasa. Perdebatan ini menyerlahkan persoalan asas tentang bagaimana Python sepatutnya mengendalikan pengaturcaraan serentak pada masa hadapan.
Masalah Function Coloring
Salah satu isu paling ketara yang mendorong perbincangan ini ialah apa yang dipanggil pembangun sebagai function coloring - keperluan untuk menandakan fungsi sebagai async dan menggunakan kata kunci await di seluruh kod asas. Ini mewujudkan perpecahan antara kod segerak dan tak segerak yang tidak dapat berinteraksi dengan mudah. Ramai pembangun membandingkan ini dengan aspect-oriented programming dari tahun 1990-an, mencadangkan ia menambah kerumitan kompiler tanpa memberikan faedah yang berkadar.
Komuniti telah menyatakan bahawa async/await memang mendedahkan lebih ramai orang kepada konsep pengaturcaraan serentak, tetapi dengan kos memerlukan mesin dalaman yang kompleks yang bocor ke dalam kod pengguna. Kerumitan ini menjadi lebih bermasalah dengan perubahan free-threading terkini Python , yang memperkenalkan kebimbangan threading bersama kerumitan async.
Istilah Teknikal Utama
- Function Coloring: Keperluan untuk menandakan fungsi sebagai async/await, mewujudkan laluan kod sync/async yang tidak serasi
- Structured Concurrency: Model pengaturcaraan di mana tugasan anak tidak boleh bertahan lebih lama daripada tugasan induk mereka
- Virtual Threads: Benang ringan yang diuruskan oleh runtime dan bukannya sistem pengendalian
- Stackful vs Stackless Coroutines: Pendekatan berbeza untuk menyimpan keadaan pelaksanaan semasa pertukaran tugasan
- Free-threading: Ciri terbaru Python yang membenarkan pelaksanaan selari sebenar tanpa Global Interpreter Lock (GIL)
Virtual Threads Sebagai Alternatif yang Lebih Mudah
Virtual threads, serupa dengan goroutines Go atau Project Loom Java , menawarkan pendekatan yang berbeza. Daripada memerlukan sintaks khas, ia akan membenarkan panggilan fungsi blocking biasa manakala runtime mengendalikan penjadualan di belakang tabir. Ini bermakna pembangun boleh menulis kod yang kelihatan mudah dan berurutan yang sebenarnya berjalan secara serentak.
Model yang dicadangkan akan menggunakan structured concurrency melalui kumpulan thread, memastikan thread anak tidak hidup lebih lama daripada induk mereka. Hubungan ini menjadikan aliran maklumat lebih jelas daripada pemboleh ubah thread-local tradisional. Walau bagaimanapun, melaksanakan ini dalam Python menghadapi cabaran disebabkan peraturan skop bahasa dan kekurangan pengisytiharan pemboleh ubah.
Pertimbangan Prestasi dan Memori
Pengkritik menunjuk kepada penyelidikan yang mencadangkan bahawa stackless coroutines (model async/await semasa) lebih cekap memori dan mempunyai kos penukaran yang lebih rendah daripada alternatif stackful seperti virtual threads. Walau bagaimanapun, ahli komuniti berhujah perbezaan prestasi ini boleh diabaikan dalam konteks Python , di mana overhed penterjemah mendominasi.
Sebenarnya tiada sebab untuk python memilih model async/await.
Perdebatan melangkaui prestasi tulen kepada produktiviti pembangun. Ada yang berhujah bahawa penyelesaian yang lebih mudah dan tidak optimum boleh menjadi lebih pantas dalam jumlah masa pembangunan, walaupun ia lebih perlahan semasa runtime.
Perbandingan Model Konkurensi
| Pendekatan | Kerumitan Sintaks | Penggunaan Memori | Pengalaman Pembangun | Prestasi |
|---|---|---|---|---|
| Async/Await | Tinggi (pewarnaan fungsi) | Rendah | Rumit | Dioptimumkan |
| Virtual Threads | Rendah (fungsi biasa) | Sederhana | Mudah | Cukup baik |
| Gevent | Rendah (monkey patching) | Sederhana | Mudah | Baik |
| Traditional Threads | Rendah | Tinggi | Rumit (kunci) | Berubah-ubah |
Cabaran Perpustakaan Dunia Sebenar
Perbincangan mendedahkan masalah praktikal dengan perpustakaan async semasa. Isu dengan pengendalian pembatalan dalam perpustakaan popular seperti yang mengendalikan I/O fail boleh menyebabkan deadlock apabila digunakan dengan corak structured concurrency. Masalah ini berpunca daripada pencampuran kod async dengan thread pool, mewujudkan situasi di mana pembatalan yang betul menjadi mustahil.
Pendekatan Alternatif Mendapat Perhatian
Beberapa pembangun menyebut pengalaman berjaya dengan gevent, yang menggunakan monkey patching untuk menyediakan multitasking koperatif tanpa function coloring. Yang lain menunjuk kepada bahasa seperti Elixir sebagai contoh model konkurensi yang lebih mudah yang mengelakkan komplikasi ini sepenuhnya.
Pendekatan ekosistem Rust juga dibincangkan, di mana pembangun boleh memilih antara model konkurensi yang berbeza daripada terkunci kepada satu pendekatan. Fleksibiliti ini membolehkan projek memilih alat terbaik untuk keperluan khusus mereka.
Melihat ke Hadapan
Walaupun virtual threads tidak dirancang secara rasmi untuk Python , perbincangan mencerminkan ketidakpuasan hati yang lebih luas dengan corak async semasa. Komuniti kelihatan berpecah antara mereka yang mahu maju dengan penambahbaikan async/await dan mereka yang menyokong peralihan asas ke arah konkurensi berasaskan thread.
Perdebatan akhirnya berpusat pada sama ada Python sepatutnya mengutamakan pengoptimuman prestasi teori atau pengalaman pembangun dan kesederhanaan kod. Apabila bahasa berkembang dengan ciri seperti free-threading, keputusan seni bina ini menjadi semakin penting untuk hala tuju masa depan Python .
Rujukan: From Async/Await to Virtual Threads