Rust, koşullu başlatma durumlarında kaynak yönetimini ele almak için Mid-level Intermediate Representation (MIR) yapım aşamasında drop elaboration kullanır. Kontrol akışına bağlı olarak bir değişkenin başlatılma durumunun belirsiz olduğu durumlarda — örneğin bir match kolunda veya bir if ifadesinde — derleyici, değişkenin yanında yığında boolean bir drop flag (aynı zamanda drop marker olarak da bilinir) ekler.
Bu koşullu başlatmanın durumunu düşünün:
let resource: File; if packet.is_control() { resource = File::create("log.txt")?; } // resource koşullu olarak başlatıldı
Bu bayrak, çalışma zamanında başlatma durumunu takip eder. Derleyici, yıkıcıyı çalıştırmadan önce bu bayrağı kontrol etmek için MIR'i dönüştürür; eğer bayrak başlatılmamış durumu gösteriyorsa, drop glue atlanır. Bu mekanizma, Drop::drop'ın her başlatılmış değer için tam olarak bir kez çağrıldığını garanti eder, farklı yolların değeri farklı durumlarda taşıması veya bırakması durumunda çift serbest bırakma veya serbest bırakma sonrası kullanımı engeller.
Yüksek performanslı bir ağ paket ayrıştırıcısı geliştirirken, File tanımlayıcıları veya Buffer yöneticileri gibi kaynakların protokol başlıklarına bağlı olarak koşullu olarak alındığını hayal edin. Sistem, saniyede milyonlarca paketi işler ve sıfır kopya işlemleri ve deterministik gecikme gerektirir.
Ayrıştırıcı, yalnızca paket tipi Control olduğunda bir günlük dosyası açmalı ve bu yapıyı içerir. Eğer tür Data ise, tanımlayıcı başlatılmamış kalır. Bu senaryoda Drop uygulamasını manuel olarak yönetmek hata yapmaya açık; bir kola başlatma durumunu kontrol etmeyi unutarak geçersiz bir dosya tanımlayıcısını kapatmaya veya yapı kapsamından çıktığında çift kapatmaya neden olabilirsiniz.
Bir potansiyel çözüm, File'ı bir Option<File> içine sarmayı içerir. Bu yaklaşım güvenli ve idiyomatik olmasına rağmen, her erişimde ayrımcı kontroller için çalışma zamanında ek yük getirir ve Option etiketi nedeniyle bellek ayak izini artırır. Yüksek hacimli ayrıştırma döngülerinde bu ek bellek trafiği, önbellek yerelliğini azaltır ve performansı önemli ölçüde etkiler.
Diğer bir çözüm, iç yapıda manuel bir boolean takip bayrağı ile eşleştirilen std::mem::MaybeUninit<File>'yi kullanmaktır. Bu, Option yükünü ortadan kaldırırken, bayrağı kontrol etmek için unsafe kod gerektirir ve ptr::drop_in_place'i çağırmadan önce uygulamak için geçerlidir. Bu, bayrağın gerçek başlatma durumu ile senkronize olmaması durumunda belirsiz davranış riski taşır, özellikle panik açma sırasında ve kod bakımını önemli ölçüde karmaşıklaştırır.
Seçilen çözüm, değişkeni yalnızca belirli match kollarında atayarak Rust'ın derleyici tarafından üretilen drop bayraklarından yararlanmaktadır. Bu, derleyicinin çalışma zamanında başlatma durumunu takip eden gizli boolean bayrakları MIR'de sentezlemesine olanak tanır. Derleyici, yıkıcıları çağırmadan önce bu bayrakları kontrol eder, böylece manuel müdahale veya unsafe blokları olmadan belirlenebilir bir temizlik sağlanır, genellikle optimizasyon geçişleri başlatma durumu kanıtlandığında bayrakları tamamen ortadan kaldırır.
Ayrıştırıcı, Option yaklaşımına kıyasla bellek ayak izinde %15'lik bir azalma sağladı ve belirsiz davranış için Miri doğrulamasını geçti. Unsafe kod bloklarının ortadan kaldırılması, güvenlik incelemeleri için denetim yüzeyini önemli ölçüde azaltmış ve gelecekteki bakımcılar için kod tabanını sadeleştirmiştir.
Drop elaboration, yığında birden fazla değer koşullu olarak başlatıldığında panik açma ile nasıl etkileşimde bulunur?
Açma sırasında, çalışma zamanının hangi değerlerin geçerli olduğunu bilmesi gerekir. Rust, MIR'de panik iniş pedlerine drop bayraklarını genişletir. Her iniş pedi, hangi yıkıcıların çalıştırılacağını belirlemek için kapsamda bulunan değişkenlerin drop bayraklarını okur. Adaylar, derleyicinin panik sırasında tüm drop'ları atladığını varsayıyor, ancak Rust, panik sırasında karmaşık koşullu dallardan geçerken bile tüm başlatılmış değerlerin bırakılmasını garanti eder. Derleyici, her olası başlatma durumu için ayrı bir temizleme bloğu oluşturur ve yığın açılma sırasında bellek güvenliğinin korunmasını sağlar.
Const fn bağlamları drop bayraklarını kullanabilir mi ve niçin ya da niçin değil?
Const değerlendirmesi, tamamen derleme zamanında MIR yorumlayıcısı içinde gerçekleşir. Const fn, yığın belleği tahsis edemez ve gerçek yığın açılması olmadan sandıklara kapatılan bir ortamda çalışır, bu nedenle drop bayrakları teknik olarak MIR'de mevcut olsa da farklı çalışır. Bunlar, sabit boolean değerler olarak değerlendirilir. Eğer bir değer const bağlamında koşullu olarak başlatılmışsa, derleyicinin başlatma durumunu derleme zamanında kanıtlayabilmesi gerekir; aksi takdirde const_err tetikler. Const bağlamlarında drop bayrakları, Drop'ın sabit yıkıcıları desteklemeyen değerlere çağrılmadığından emin olmak için kullanılır ve derleme zamanı yürütmesinin keyfi çalışma zamanı yıkıcılarını çalıştıramayacağı kısıtlamasını zorlar.
Bir değişkenin bir maç kolunda bir değeri taşımak drop bayrağı gerektirmezken, kısmi başlatma neden gerektirir?
Bir değer koşulsuz olarak taşındığında, Rust, orijinal değişkeni taşınmış ve başlatılmamış olarak kabul eder. Derleyici, özellikle o yol için yıkıcının çalıştırılmayacağını statik olarak bilir. Ancak, koşullu başlatmada — bir kol başlatırken ve diğeri başlatmıyorken — derleyici hangi dalın alındığını derleme zamanında bilemez. Bu nedenle, çalışma zamanı drop bayrağı gerektirir. Adaylar bunu NLL (Non-Lexical Lifetimes) ile karıştırır ve ödünç alma kontrol etmekle ilgilendiğini düşünür; gerçekte, NLL ödünç alımları yönetirken, drop elaboration başlatma durumunu yönetir. Ayrım önemlidir: NLL, ödünç alımları erken bitirir, ancak drop bayrakları bir değerin bırakılacak olup olmadığını takip eder.