Evet arkadaşlar, şimdi mahkemenin bu bölümünde dinleyici konuları kavramını anlayacağız.
Dolayısıyla, bir uygulamanın sürekli olarak harici olayları dinlemesi çok yaygın bir senaryodur.
Doğru.
Bu harici olaylar, bir uygulamanın bu olayları doğru şekilde işlemesi gereken herhangi bir zamanda gelebilir.
Böylece uygulama bu harici olayları dinlemek için iş parçacıkları kullanabilir.
Yani buradaki tüm iş parçacıklarını, bir uygulamanın herhangi bir zamanda
alabileceği bu harici olayları sürekli dinleyen bir araba gibi kullanırlar.
Şimdi bunu resimsel gösterimle anlamaya başlayalım.
Diyelim ki sistemde çalışan bir B Süreciniz var ve bu
sürecin birden fazla harici olayı dinlemesini istiyorsunuz, değil mi? Dolayısıyla
ilk gereksinimimiz, bir sürecin herhangi bir zamanda değil, dışarıdan gelebilecek
bir B paketini gerçekten alabilecek bir konumda olması gerektiğidir.
Doğru.
Bunun için B süreciniz bir üçlü oluşturabilir, biz buna yapılacaklar listesi diyoruz.
Bu başlığın sorumluluğu sadece herhangi bir
paketin ulaşıp ulaşmadığını izlemek değildir.
Doğru.
Paket gelmemişse, bu paket dinleyici iş parçacığı paketin
orada olup olmadığını görmek için izlemeye devam edecektir.
Ve eğer paket bu pakete ulaştıysa, ya paket okunmaz
ya da paket işlenir veya ana sürece teslim edilir.
Paket işleme için olun.
Değil mi? Yani B Süreci kendi
başına dış dünyadan gelen herhangi bir
paketi dinlemek veya izlemekle meşgul değildir.
Ancak bu işi paket dinleyici iş parçacığı olarak adlandırdığımız ayrı bir iş
parçacığına devretti, değil mi? Süreç başka bir iç mantığı yürütmekle meşgul olabilir.
Doğru mu? Benzer şekilde, b
işleminiz altta yatan işletim sisteminden
bildirilen bazı olayları bekliyor olabilir.
Altta yatan işletim sistemini çekirdek hakkı olarak adlandırıyoruz ve
B sürecinin çekirdekten bildirilecek bazı olayları beklemesi çok olasıdır.
Bu durumda, tüm süreç kernel even dinleyici iş
parçacığı olarak adlandırdığımız ikinci bir iş parçacığı oluşturabilir,
değil mi? Bu iş parçacığının sorumluluğu sadece dinlemek
ve olay geldiğinde kernel even'ın gelmesini beklemektir.
Bu iş parçacığı ya olayı kendi başına işler ya
da olayları işlemesi için B Sürecine devreder, değil mi?
Benzer şekilde, p işleminizin kullanıcı girdisini gerçekten beklemesini istersiniz.
Değil mi? Bu işlem için kullanıcı girişi dinleyici
iş parçacığı adında üçüncü bir iş parçacığı oluşturabiliriz.
Ve bu iş parçacığının sorumluluğu sadece kullanıcının herhangi bir girdi sağlamasını beklemektir.
Giriş, Seelye arayüzü veya GUI arayüzü kullanılarak sağlanabilir.
Önemli değil, değil mi? Yani kullanıcı girdisini bekleme sorumluluğu
kullanıcı girdi listesi adı verilen yeni parçaya devredildi, tehdit
yok, değil mi? Başka bir senaryoda, bir B süreci,
aynı sistem üzerinde çalışan başka bir b dash sürecinden
bazı veriler veya bir tür olay bekliyor olabilir.
Doğru.
Bu durumda, süreç çalışanlarınız süreç iletişim dizisi adı
verilen dördüncü bir üçlü oluşturmaya karar verir.
Bu iş parçacığının sorumluluğu sadece başka bir
süreçten bildirilen bazı olayları veya verileri beklemektir.
Ash aynı sistemde
mi çalışıyor? Doğru.
Dolayısıyla, tüm bu programa bütüncül bir bakış açısıyla bakarsanız, tüm gıda tehditlerinin, bu hiç kimse,
bu iki numaralı tehdit, bu üç numaralı tehdit ve dört numaralı hedef olduğunu görürsünüz.
Dört tehdit de engelleme durumundadır.
Engelleme durumu, harici bir varlıktan gelen bir girdi için bile bekledikleri anlamına gelir.
Bu harici varlık kullanıcı olabilir, albay olabilir, çalışmıyor olabilir ya da
başka bir şey olabilir, değil mi? Dolayısıyla, sürecinizin blok durumunda
olmasını istemezsiniz çünkü süreciniz kendi iç mantığını yürütmekle meşgul olabilir.
Ve bu nedenle, ana mantığınızın bir olayı beklerken bloke olmasını
istemediğiniz için, süreç p dinleyici tehditleri yaratır, değil mi?
Bu dinleyici tehditler süreç adına bir köle gibi çalışır.
Dışarıdan bir olayın gelmesini bekliyor olmak.
Tamam.
Böylece dinleyici iş parçacıkları kullanarak, süreç tüm olayları aynı anda dinleyebilir.
Ve olay geldiğinde, süreciniz bu olayları işleyebilecek bir konumda olmalıdır, değil mi?
Bu yüzden bu bölümde alıştırma olarak bir B Süreci yazmayı bekliyoruz.
Bu nedenle, kursun bu bölümü için bir gösteri
olarak yazacağımız kod, insanların sorumluluğu harici olayları dinlemek
olan köle etiketleri oluşturacak bir B süreci yazacaklarıdır.
Bu nedenle, herhangi bir soket programlama deneyiminiz olmasa bile, kursun
bu bölümü için biraz soket programlama deneyimine ihtiyacınız var.
Yine de kursun bu bölümüne devam etmenizi tavsiye ederim çünkü soketle
ilgili herhangi bir programlama, eğer müsait değilseniz, benim kodumu kopyalayıp yapıştırabilirsiniz.
Ancak sonuçta, hiç soket programlama deneyiminiz olmasa bile, dinleyici
iş parçacığı kavramını kullanarak birden fazla harici olayı
dinleyebilen bir sürecin veya uygulamanın nasıl tasarlanacağını anlayacaksınız.
Yani yapacağımız şey, uygulamamızın yanı sıra birden fazla
ağ UDP soketini dinleyeceğimiz bir uygulama uygulayacaktık.
Aynı zamanda, kullanıcı girdisini bekleyeceğiz.
Doğru.
Yani bunlar, uygulamanın dinleyeceği iki harici olaydır. Harici
olayı dinleme tekniği, olayın türüne bakılmaksızın aynıdır.
Dolayısıyla, bu örnekte ya da tanıtım programında, çekirdek olaylarını
dinlemeyi ya da diğer süreçlerin olaylarını dinlemeyi ele almadık.
Bunun nedeni, herhangi bir çekirdek programlamasından haberdar olmadığınızı ve
süreçler arasındaki süreç içi iletişimden haberdar olmadığınızı varsaymamdır.
Doğru.
Ancak dediğim gibi, olayların türüne bakılmaksızın dışarıdan dinleme tekniği aynıdır.
Bu basitçe, harici bir olayı dinlemek için bir bağımlı
iş parçacığı konuşlandırmanın olay türüne bağlı olmadığı anlamına gelir.
Yani eğer yarın, çekirdek olaylarının iki süreç arasındaki iletişime girdiğini
öğrenirseniz, çekirdek olaylarını ve diğer süreçlerden gelen olayları dinlemek
için kursun bu bölümünde uygulayacağımız aynı tasarımla devam edebilirsiniz.
Değil mi? Uygulayacağımız uygulamanın temel tasarımı
değişmeyecek ve kursun bu bölümü için
tüm kodlar bu dizinde bulunabilir, değil
mi? Multithreading Bible slash olay dinleyicileri.