Michael Tsai – Blog – Visi Swift: Meningkatkan Pendekatan Keamanan Perlombaan Data

Holly Borla (melalui mastodon, forum):

Dokumen ini menjabarkan beberapa jalur potensial untuk meningkatkan kegunaan Swift 6, terutama dalam situasi sederhana di mana pengguna tidak bermaksud menggunakan konkurensi sama sekali.

(…)

Prinsip utama pemikiran kami dalam visi ini adalah kami ingin secara drastis mengurangi jumlah anotasi konkurensi eksplisit yang diperlukan dalam proyek yang tidak mencoba memanfaatkan paralelisme untuk kinerja. Hal ini penting untuk berbagai jenis pemrograman, seperti pemrograman dan skrip UI, yang mana konkurensi sering kali dilokalisasi dan sebagian besar kode umumnya diharapkan dibatasi pada aktor utama. Pada saat yang sama, kami ingin menjaga kelancaran bagi pemrogram berpengalaman untuk ikut serta dalam konkurensi dan menjaga keamanan pemeriksaan data race secara menyeluruh.

(…)

Kami percaya bahwa solusi yang tepat untuk masalah ini adalah dengan mengizinkan kode untuk ikut serta menjadi “single-threaded” secara default, berdasarkan modul demi modul. Hal ini akan mengubah aturan isolasi default untuk kode yang tidak diberi anotasi dalam modul: alih-alih menjadi non-isolasi, dan oleh karena itu harus berurusan dengan anggapan konkurensi, kode tersebut akan diisolasi secara implisit ke @MainActor. Kode yang diimpor dari modul lain tidak akan terpengaruh oleh pilihan default modul saat ini.

(…)

Menambahkan pengaturan per modul untuk menentukan isolasi default akan memperkenalkan dialek bahasa permanen yang baru. (…) Secara keseluruhan, kami merasa bahwa dampak dari dialek khusus ini tidak terlalu besar dan dapat dikelola.

(…)

Hal yang paling penting untuk model kode single-threaded kami adalah kemampuan untuk mengekspresikan kesesuaian yang terisolasi dari aktor global. Ketika suatu tipe diisolasi ke aktor global, metodenya akan diisolasi secara default. Biasanya, metode ini bukan merupakan implementasi hukum dari persyaratan protokol yang tidak terisolasi. Ketika Swift menyadari hal ini, Swift dapat dengan mudah menganggap kesesuaian tersebut sebagai sesuatu yang terisolasi dari aktor global tersebut. Ini semacam kesesuaian yang terisolasiyang akan menjadi konsep baru dalam bahasa tersebut.

Marcin Krzyzanowski:

Apa yang saya keluhkan sejak Aktor pertama kali diperkenalkan ke Swift adalah bahwa hal itu memaksa pemrograman “async-first” alih-alih “sync-first”. Saya sangat senang Kelompok Pengarah Bahasa Swift akhirnya menyadarinya.

Christian Tietze:

Begitu banyak upaya yang dicurahkan untuk hal ini, dan kemudian masalah DX dapat diringkas seperti “Anda tidak dapat lagi dengan mudah menulis kode single-threaded sekarang” 🤯

Max Seelemann:

Oleh karena itu, untuk visi yang luas, saya kehilangan liputan masalah saat ini dengan ketidakcocokan perilaku isolasi dengan kode Objective-C dan pustaka sistem Objective-C.

Sampai saat ini, sebagian besar pengembangan platform baru Apple masih dilakukan di ObjC, dan banyak – jika bukan sebagian besar – pengembang platform Apple tidak dapat menghindari UIKit atau AppKit dalam pekerjaan mereka sehari-hari. Namun bahasa ini tidak mengetahui apa pun tentang konkurensi yang ketat dan memungkinkan pemrograman yang nyaman dengan cara yang sangat tidak kompatibel. Yang sangat saya rindukan adalah alat untuk menjembatani kesenjangan ini, untuk membuat penggunaan API dari Swift 6 senyaman dari Swift 5 atau ObjC.

(…)

Yang terpenting, bagi saya, kita memerlukan cara yang lebih kuat dan fleksibel untuk mendeklarasikan dinamika MainActor isolasi. Pada dasarnya MainActor.assumeIsolated tetapi untuk seluruh kelas dan tanpa semua tarian yang dapat dikirim untuk melewati dan keluar dari penutupan itu. (#isolation menjadi non-nihil ketika dipanggil dari thread utama ObjC juga akan menyenangkan.)

(…)

Saya kesulitan untuk menulis ini dengan lebih tepat dalam istilah abstrak, jadi saya ingin memberikan contoh dari pekerjaan saya baru-baru ini dengan TextKit2 – sistem iOS/macOS API yang cukup baru, yang dipikirkan dan ditulis seluruhnya dalam ObjC.

Victor_Martins:

Pemahaman saya adalah bahwa dokumen tersebut mengatakan bahwa salah satu alasan mengapa analisis program secara keseluruhan buruk adalah karena “hal ini akan membuat penerapan konkurensi pertama kali menjadi sangat menyakitkan”. Kemudian, pendekatan yang lebih baik adalah dengan membuat asumsi single-thread di bagian program yang lebih kecil. Terakhir, dokumen tersebut mengusulkan agar bagian-bagian yang lebih kecil ini disebut modul.

Memilih modul sebagai bagian yang lebih kecil telah menarik perhatian saya karena selama 3 tahun terakhir saya telah berinteraksi dengan puluhan programmer Swift pemula dan sebagian besar aplikasi yang saya lihat mereka kembangkan tidak memiliki kode yang mereka miliki. ditulis dipecah dalam modul yang lebih kecil. Aplikasi sebagian besar terdiri dari 1 modul + dependensi.

Apakah keluar dari default single-thread pada proyek-proyek ini dengan satu modul besar mungkin akan sangat menyakitkan?

Sebelumnya:

Pembaruan (26-11-2024): Rob Jonson:

Saya pikir Anda benar jika berfokus pada hal ini – namun saya berpendapat untuk pendekatan yang sangat berbeda.

(…)

Balikkan defaultnya. Standarnya adalah jaminan keamanan data race dinonaktifkan. (…) Pindah ke model keikutsertaan akan mengubah dinamika. Saat ini, rasanya seperti kita sedang dalam perjalanan paksa menuju tempat yang dijanjikan akan keselamatan Swift 6. Jika keselamatan diikutsertakan, maka pengembang akan memilih untuk menggunakannya karena menjadi lebih ergonomis. Jika fitur tersebut harus sepadan dengan usahanya untuk meyakinkan orang untuk ikut serta, – dinamika seputar desain akan lebih fokus pada penggunaan nyata.

(…)

Analisis kode adalah alat yang hebat saat kita beralih ke arc (dan bahkan setelahnya). Jalankan alat tersebut, periksa peringatan tentang keamanan memori, perbaiki jika perlu. (…) Konkurensi dapat melakukan hal yang sama. Analisis dapat memperingatkan saya bahwa mengembalikan NSImage berpotensi tidak aman jika pengirim menyimpan dan mengubah yang asli – tetapi saya dapat memilih untuk mengabaikannya karena saya tahu saya tidak melakukannya.

Saya tidak yakin saya setuju dengan hal ini, tapi ini menarik untuk dipertimbangkan.

Tim:

Saya ingat argumen yang sama persis tentang opsional ketika Swift pertama kali dirilis. “Saya tahu apa yang saya lakukan”. “Kompilator sedang mencoba untuk mengasuh saya” dll. Memahami opsional jelas jauh lebih mudah daripada konkurensi, tetapi ini adalah fitur bahasa yang sama yang menangani kesalahan pemrograman umum dan saya pikir kita semua bisa sepakat bahwa ini adalah fitur hebat setelah dipahami.

Saya selalu mendukung opsi, namun menurut saya cara lain dalam memandang hal ini adalah bahwa orang dengan cepat melihat bahwa opsi memberikan manfaat nyata dalam keandalan dan kejelasan kode dengan biaya yang sangat kecil (kognitif atau visual). Di luar itu async/await gula, biaya Swift Concurrency tampaknya jauh lebih tinggi dan manfaatnya kurang jelas.

Desain Bahasa Konkurensi Pemrograman Objective-C Kit Teks Bahasa Pemrograman Swift Konkurensi Swift

9 Komentar