WEBVTT 00:05.210 --> 00:09.380 Şimdi temizlik işleyicileriyle ilgili hatırlanması gereken bazı noktaları tartışalım. 00:09.590 --> 00:16.750 Bu nedenle, push'un derleme zamanında parantez açma ve bazı ara kodlarla değiştirildiğini düşünün. 00:16.760 --> 00:21.950 Sol tarafta, bir iş parçacığı bağlamında çalışacak bir iş parçacığı işlevimiz olduğunu görebilirsiniz. 00:21.950 --> 00:29.360 Ve bir geliştirici olarak bu fonksiyona iş parçacığı temizleme, push API, çağrısı eklediğinizi varsayalım. 00:29.360 --> 00:30.140 Değil mi? 00:30.140 --> 00:37.220 Bu nedenle, p thread cleanup push işlevinin aslında bir işlev olmadığını, derleme sırasında bazı kodlara genişleyen 00:37.220 --> 00:40.040 bir makro olduğunu unutmayın. 00:40.040 --> 00:40.850 Doğru. 00:40.850 --> 00:48.440 Bu nedenle, p thread cleanup push makrosunun açılış parantezlerine ve ardından derleyici tarafından eklenen bazı kodlara genişleyeceğini 00:48.440 --> 00:50.690 hayal etmeye çalışın. 00:50.720 --> 00:51.610 Doğru. 00:51.680 --> 00:58.460 Benzer şekilde, iş parçacığı işlevinize p thread cleanup push API'sine iki çağrı eklerseniz, bu, kodunuza iki 00:58.460 --> 01:04.580 açık küme parantezinin ekleneceği ve ardından derleyici tarafından eklenen ve iş parçacığı temizleme 01:04.580 --> 01:10.500 rutini yığınının yönetiminden sorumlu olan başka bir kodun ekleneceği anlamına gelir. 01:11.580 --> 01:19.740 Benzer şekilde, derleme zamanında pop'un yerini bazı ara kodların ve ardından kapama parantezlerinin alacağını hayal 01:19.740 --> 01:21.090 etmeye çalışın. 01:21.090 --> 01:21.780 Doğru. 01:21.780 --> 01:29.040 Yani sol tarafta, bir programcı olarak derleme zamanında thread fonksiyonuna açılır API çağrısı eklerseniz, 01:29.040 --> 01:35.640 bu çağrı derleyici tarafından oluşturulan bazı kodlarla değiştirilecek ve ardından parantezler 01:35.640 --> 01:37.110 açılacaktır. 01:37.140 --> 01:37.860 Doğru. 01:38.830 --> 01:45.130 Artık programınızda dengesiz parantezler varsa, programınızın derlenmeyeceğini 01:45.130 --> 01:47.050 zaten biliyorsunuz. 01:47.080 --> 01:54.250 Benzer şekilde, programınızda push ve pop API'lerine dengesiz çağrılar varsa, programınız yine derlenmeyecek 01:54.250 --> 02:00.490 ve programınızda dengesiz parantezler olmasıyla aynı hatayı verecektir. 02:00.520 --> 02:01.300 Doğru. 02:01.720 --> 02:08.620 Demo amacıyla, fonksiyonumuzdan pop çağrılarından birini kaldırdığımı varsayalım. 02:08.620 --> 02:09.280 Değil mi? 02:09.310 --> 02:13.810 Şimdi bu fonksiyonu derlemeye çalışırsanız, aynı hatayı alırsınız, değil mi? 02:13.900 --> 02:17.260 Girdinin sonunda beklenen bildirim veya ifade. 02:17.290 --> 02:21.370 Bu hata, programınızda dengesiz parantezler olduğunda ortaya çıkar. 02:22.600 --> 02:30.130 Bu temizleme, pop ve temizleme itme API'lerinin, açma veya küme parantezleri ve ardından bazı kodlarla genişleyen makrolar 02:30.130 --> 02:31.870 olduğunu unutmayın. 02:31.900 --> 02:32.590 Doğru. 02:32.920 --> 02:36.860 O zaman temizleme işleyicileri hakkında hatırlanması gereken bazı noktaları hızlıca tartışalım. 02:36.880 --> 02:43.700 Bu nedenle, push'u açılış parantezleri ve pop'u kapanış parantezleri olarak hayal ederek programınızda her zaman parantezlerin 02:43.700 --> 02:45.520 dengeli olduğundan emin olun. 02:45.530 --> 02:46.250 Doğru. 02:46.670 --> 02:49.340 Ve pthread cleanup pop API'sinde. 02:49.340 --> 02:56.540 Eğer argüman olarak sıfır geçerseniz, bu sadece bu API'ye yapılan çağrının yığının tepesinden bir fonksiyonu 02:56.540 --> 02:59.010 kaldıracağı anlamına gelir. 02:59.030 --> 03:02.540 Yığın dediğimde, iş parçacığı temizleme yığını kastedilmektedir. 03:02.570 --> 03:09.500 Benzer şekilde, thread cleanup pop API'sine sıfır dışında herhangi bir değer geçerseniz, bu API'ye yapılan çağrı 03:09.500 --> 03:15.920 yalnızca temizleme rutinini yığının en üstünden çıkarmakla kalmaz, aynı zamanda bu rutini de çağırır. 03:15.920 --> 03:16.670 Doğru. 03:16.700 --> 03:23.990 Böylece, bu cleanup pop API'sine argüman olarak sıfır değerini geçmek ile bu cleanup pop API'sine argüman olarak sıfır olmayan 03:23.990 --> 03:27.590 bir değer geçirmek arasındaki farkı fark edebilirsiniz. 03:27.620 --> 03:28.370 Doğru. 03:28.850 --> 03:33.210 İş parçacığı p thread exit kullanılarak sonlandırıldığında temizleme işlevleri de çağrılır. 03:33.230 --> 03:33.890 Doğru. 03:33.890 --> 03:40.250 Dolayısıyla, işleviniz basitçe p thread exit kullanarak sonlandırılırsa, bir iş parçacığının 03:40.250 --> 03:47.740 temizleme yığınında bulunan tüm temizleme işleyicileri çağrılacak ve sonunda yığından kaldırılacaktır. 03:47.780 --> 03:53.240 Bu nedenle, temizleme işleyici işlevleriniz herhangi bir nedenle çağrıldığında, diyelim ki iş parçacığınız 03:53.240 --> 03:59.060 iptal sinyali aldı veya iş parçacığınız p iş parçacığı çıkış çağrısı kullanılarak sonlandırıldı. 03:59.090 --> 04:01.880 Ayrıca yığından da çıkarılırlar. 04:03.170 --> 04:07.930 İş parçacığı temizleyici işlevlerinizin çağrılması ancak yığından kaldırılmaması söz konusu değildir. 04:07.940 --> 04:12.410 Çağrılırlarsa, iş parçacığının temizleme yığınından da kaldırılırlar. 04:13.110 --> 04:19.050 Ve son olarak, iş parçacığının yığınında bulunan temizleme işlevleri, iş parçacığı basit bir return deyimi sayesinde 04:19.050 --> 04:21.400 sonlandırıldığında çağrılmaz. 04:21.420 --> 04:22.650 Bu kadar basit. 04:22.650 --> 04:23.250 Doğru. 04:24.850 --> 04:31.330 Aynı örneğimize gelirsek, bu, dosyaya yazan bir iş parçacığı bağlamında çalışan 04:31.360 --> 04:32.980 işlevdir. 04:33.010 --> 04:40.480 Şimdi, diyelim ki fonksiyonumu on kez çalıştırmak istiyor olabilirim, değil mi? 04:40.480 --> 04:48.190 Yani buraya basitçe int is equal to ten yazacağım ve diyelim ki A is less than equal to ten koşulunu 04:48.190 --> 04:50.530 yazacağım, değil mi? 04:50.530 --> 04:54.960 Ve basitçe A'nın değerini bir artıracağım. 04:54.970 --> 04:58.480 Yani while döngüm şimdi on kez yinelenecek. 04:58.480 --> 05:05.200 Bunu, iş parçacığı işlevimin sonsuz bir döngü içinde çalışmaması ve sonunda iş parçacığı 05:05.200 --> 05:13.060 işlevimin iptal sinyalini almadan bu temizleme pop API'lerini doğru şekilde çağırması için yaptım. 05:13.060 --> 05:13.770 Doğru. 05:13.780 --> 05:20.260 Şimdi bu işlev iş parçacığım tarafından çağrıldığında, bu while döngüsü on yinelemeden sonra sona erdiğinden, 05:20.290 --> 05:26.300 yine de temizleme işleyicilerimi çağırmak istiyorum çünkü belleği boşaltmak ve bu dosyayı kapatmak 05:26.300 --> 05:27.320 istiyorum. 05:27.320 --> 05:28.090 Değil mi? 05:28.100 --> 05:33.890 Bu durumda, bu API'lere argüman olarak sıfır olmayan bir değer iletirim. 05:33.890 --> 05:34.670 Değil mi? 05:34.880 --> 05:42.440 Bu pop API'ye sıfır olmayan bir argüman ilettiğinizde, bu pop API yalnızca temizleme yığınından bir temizleme işleyicisini 05:42.440 --> 05:46.550 kaldırmakla kalmaz, aynı zamanda bu işleyicileri de çağırır. 05:46.760 --> 05:52.700 Burada dikkat edilmesi gereken bir diğer husus da, diyelim ki dosyanızın açılması başarısız oldu, değil mi? 05:53.620 --> 05:56.970 Yani f open bana bir null pointer döndürecek demektir. 05:56.980 --> 06:02.350 Yani bu, bu koşulun doğru olacağı ve fonksiyonumdan geri dönmeye çalışacağım anlamına geliyor. 06:02.380 --> 06:08.440 Şimdi, normal return deyimini kullanarak fonksiyonumdan döndüğümde temizleme işleyicilerinin çağrılmadığını 06:08.440 --> 06:09.730 hatırlayın. 06:09.760 --> 06:14.160 Bu basitçe, bu belleği serbest bırakamayacağım anlamına geliyor. 06:14.170 --> 06:14.980 Doğru. 06:15.100 --> 06:23.140 Bu nedenle, işlevinizden her döndüğünüzde basit return deyimi yerine genellikle p thread alt çizgi exit 06:23.140 --> 06:26.140 çağrısını kullanmaya dikkat edin. 06:26.140 --> 06:26.880 Doğru. 06:26.890 --> 06:32.950 Çünkü p iş parçacığı çıkışının çağrılması temizleme işleyicilerini çağıracak ve temizleme işleyicileri 06:32.950 --> 06:38.500 iş parçacığınız tarafından işgal edilen tüm kaynakları serbest bırakmaya özen gösterecektir. 06:38.530 --> 06:39.250 Değil mi? 06:39.520 --> 06:45.100 Bu nedenle, iptal edilebilen bir iş parçacığı uyguluyorsanız, normal return deyimini kullanmak yerine 06:45.100 --> 06:49.150 p thread exit kullanarak iş parçacığınızdan dönmek daha mantıklıdır. 06:49.180 --> 06:49.950 Doğru. 06:49.960 --> 06:56.060 Ve daha önce de açıkladığım gibi, p iş parçacığı çıkışı, iş parçacığınız tarafından tahsis edilen kaynakları temizleyecek 06:56.060 --> 07:01.430 olan temizleme işleyicilerini çağıracak ve basit bir return deyimi kullanarak size kaynak sızıntısı 07:01.430 --> 07:03.350 sorunu verecektir. 07:03.350 --> 07:04.070 Doğru. 07:05.240 --> 07:11.390 Başka bir yol da P thread exit zero kullanarak goto deyimini kullanabilir ve clean up işleyicilerine 07:11.390 --> 07:18.590 git diyebilirsiniz, clean up'ı bir etiket olarak kullanabilir ve sonunda bu etiketi tanımlayabilirsiniz, değil 07:18.740 --> 07:19.550 mi? 07:20.150 --> 07:22.670 Yani bu aynı şey, değil mi? 07:22.850 --> 07:25.420 Bu da aynı şeyi başarmanıza yardımcı olacaktır. 07:25.430 --> 07:32.240 Sonuç olarak, iş parçacığından her döndüğünüzde, iş parçacığınız tarafından tahsis edilen veya işgal edilen 07:32.240 --> 07:38.540 kaynakları serbest bıraktığınıza dikkat edin, doğru, bunu ne şekilde başarmak isterseniz.