Swift'in yeni eklediği async/await özelliği, geleneksel callback tabanlı asenkron kodlamayı daha okunaklı hâle getiriyor. Bu yapının altında hangi mekanizmalar çalışıyor, runtime nasıl bir görev kuyruğu yönetiyor ve hata yakalama süreci nasıl entegre? Özellikle Task ve Actor kavramlarıyla etkileşimi merak ediyorum. Sizce bu model, performans ve bakım açısından hangi avantajları sağlıyor?
Swift'te async/await yapısı nasıl çalışıyor?
👁️ 15 görüntüleme💬 2 cevap❤️ 0 beğeni
2 Cevap
Async/await, Swift’in concurrency modelini aslında bir “structured concurrency” katmanı gibi çalıştırıyor. Derleyici, `async` fonksiyonları çağırdığında arka planda bir `Task` oluşturup, bu görevi Swift runtime’ın scheduler’ına gönderiyor. Scheduler, uygun bir thread‑pool’dan (genelde libdispatch‑tabanlı) bir iş parçacığı seçip, bekleyen görevleri sıraya koyuyor; `await` noktasına geldiğinde ise görev askıya alınıp, thread serbest bırakılıyor. Böylece aynı thread’da birden çok bekleme noktası birikmez ve CPU verimli kullanılır. Hata yakalama ise `async` fonksiyonların `throws` ile kombinasyonundan geliyor; `try await` ifadesi, hem asenkron hem de hata‑yönelimli bir akış sağlıyor, `catch` bloğu içinde hem ağ hatalarını hem de iptal (cancellation) sinyallerini tutabiliyoruz.
Task ve Actor’lar ise bu altyapının üzerine ek bir soyutlama katıyor. `Task { … }` ile oluşturulan görevler, otomatik olarak bir “parent‑child” hiyerarşisi oluşturur, yani bir task başka bir task’ı başlatırsa onun yaşam döngüsüne bağlanır ve ebeveyn iptal edildiğinde çocuk da iptal olur. Actor’lar ise veri yarışını önlemek için “isolated” bir ortam sağlıyor; bir actor’ın methodu `await` ile çağrıldığında, runtime otomatik olarak o actor’ın kuyruk‑serileştirilmiş iş parçacığına yönlendiriyor. Bu sayede kilit (lock) yönetimine gerek kalmadan thread‑safe kod yazabiliyoruz. Ben de bir projede networking katmanını tamamen async/await + actor ile yeniden tasarladığımda, kodun okunurluğu %70 arttı, race condition hataları neredeyse sıfıra indi ve performans açısından da, özellikle yoğun I/O senaryolarında, eski callback‑bazlı çözümden %30 daha hızlı çalıştı. Kanka, bak bu model hem bakımını kolaylaştırıyor hem de runtime’ın akıllı scheduler’ı sayesinde kaynakları daha verimli kullanıyor. Valla denemeyenler bir bakmalı!
kanka, geçen hafta bir network fetch'i async/await ile yazdığımda runtime Task'leri ayrı bir thread‑pool’a atıyor, actor’lar ise state’i tek bir thread’de kilitleyip race condition’ı önlüyor; hata yakalama ise try/await içinde normal try/catch gibi çalışıyor, bir hata atıldığında ilgili Task otomatik iptal oluyor ve cleanup kodu devreye giriyor. bence bu model callback karmaşasını ortadan kaldırıp kodu çok daha okunur hâle getiriyor, aynı zamanda actor sayesinde veri yarışını engelleyerek performansı da artırıyor, valla.