Şimdi, genellikle bir zamanlayıcı oluşturduğumuz Create API zamanını tartışalım.
Şimdi zamanlayıcının yaratılışıyla ilgili bazı teorileri tartışalım.
Zamanlayıcılarımızı uygularken işleri hızlı bir şekilde görebilmemiz
için mümkün olduğunca çok askeri kapsamak istiyorum.
Hızlı bir şekilde klavyeye basmaya geçebilir ve işleri eylem halinde görebiliriz.
Bu yüzden bu sefer etrafımızda oluşturduğumuz bu API ile başlayacağız, değil mi? Bu
API'nin üç argüman kabul ettiğini görebilirsiniz, ilk argüman şu anda oluşturduğunuz zamanlayıcı
türüdür Linux işletim sistemi Politika API'miz farklı türde zamanlayıcılar oluşturmanıza izin verir.
Bu nedenle, farklı zamanlayıcı türlerinin tartışılmasının aslında burada çok değerli olmadığını düşünüyorum.
Bu yüzden size gerçek zamanlayıcı türünü uygulayarak göstereceğim çünkü başka zamanlayıcı türleri
de var, ancak bu zamanlayıcılar o kadar yaygın olarak kullanılmıyor ve çoğu
senaryoda uygulamalarını garanti eden zamanlayıcı türü en yaygın dağıtımlarda gerçek zamanlayıcılardır.
Dolayısıyla, ayrıştırmamız gereken ilk argüman sabit değerdir, bu
da bunu temsil eder, ne tür bir zaman
oluşturmak istiyorsunuz? İkinci parametreler aslında geliştiricinin veya programcının
zamanlayıcıları kontrol eden çeşitli parametreleri belirtmesine olanak tanır.
Değil mi? Bu parametrelerin ne olduğunu birazdan ayrıntılı olarak
tartışacağız. Ve üçüncü argüman zamanlayıcıya bir işaretçidir, değil mi?
API başarı durumunda sıfır yazar, aksi takdirde hata durumunda
eksi bir döndürür ve global değişken hata numarası
ne tür bir hata oluştuğunu göstermek için ayarlanır.
Şimdi bu global değişken hata dosyasında tanımlanmıştır, şüphesiz edge.
Ve bu sayıyı her zaman belirtilen yüzdeleri kullanarak
yazdırabilirsiniz, değil mi? Yani şimdi büyük geri
dönüşlerin zamanı eksi bir, bu hatayı yazdırarak
hataya neyin neden olduğunu görebilirsiniz? Değişken yok.
Şimdi, zamanlayıcının bu kontrol parametrelerini tartışalım, bu nedenle zamanlayıcının bu kontrol
parametreleri bir veri yapısı olan SIG olayı ile temsil edilir.
Doğru mu? Şimdi, yapıların durumu içinde, değerini
belirtmemiz gereken üç üye vardır, ilk
üye bir SIG evey bildirim işlevidir.
Yani, zamanlayıcı sona erdiğinde buraya aktarmamız gereken zamanlayıcı geri arama işlevi işaretçisidir.
Çağrılacak olan bu işlevi yapar, değil mi?
Ve bu fonksiyon çağrılacağı zaman, bu fonksiyona
bazı argümanları duraklatmak için de ses çıkarır.
Bu argüman, bu veri yapısının ikinci bir parametresi tarafından belirtilir.
Bu hasta ortam değerlidir, sinyal değeri işaretçisi değildir.
Doğru.
Ve bu üye, bu zamanlayıcı geri çağırma işlevine bir
argüman olarak ayrıştırılacak olan bellek yığınının adresini gösterir.
Doğru.
Bu nedenle, bellek ayırmak ve ilgili verileri ve bu belleği yerleştirmek ve bu
EVP veri yapılarının bu belirli üyesini bu bellek adresiyle başlatmak uygulamaların sorumluluğundadır.
Doğru mu? Üçüncüsü, IGB Bildirim üyesi her zaman AIG
gibi bu sabite kodlandığından, bu sabiti belirterek tehdidin altını
çiziyoruz, aslında albaydan bir zaman başlatmasını veya zamanı çağırmasını
veya geri çağırmasını istiyoruz, değil mi? Aslında albayın geri
arama işlevini yürütebileceği başka yollar da vardır, zamanlayıcının
süresinin dolması gerekmez, ancak başka şekillerde de çağırabilir.
Burada tartışmak için önemli olmayan diğer yollar nelerdir
çünkü şu anda bu geri arama işlevine gelen
zamanlayıcılarla uğraşıyoruz? Bu geri çağırma fonksiyonunun prototipi veya
imzası ne olmalıdır? Bir prototipi olmalı, değil mi?
Yani bu geri çağırma fonksiyonunun prototipi sabittir
ve bu fonksiyon silinmiş hiçbir şey döndürmemelidir.
Ve bu fonksiyonun argümanı bir veri tipi union signal'dır.
Şu anda, Union Signal gibi bu yeni veri yapılarının SIG olayı olduğunu
duymanın biraz tedirginlik yaratma eğiliminde olan bir şey olduğunu anlıyorum, ancak bu
veri yapılarının kullanımı çok basit değil, örneğin ve veri yapıları bile arayın.
Tek yapmanız gereken bu üç üyeyi başlatmaktır.
Öyle değil mi? Benzer şekilde, Union
SIG için de yapılar vardır.
Tek yapmanız gereken yüksek değerli bir işaretçi olan bu üyeye erişmektir, değil
mi? Yani aslında, yosun noktası, belirttiğim gibi, bu argümanın adresiyle aynıdır.
Değil mi? Çünkü günün sonunda amacımız, bu argümanla temsil edilen
kullanıcı tanımlı veri yapılarıyla belirli bir geri çağırma işlevi olan
uygulamayı çağırmaktı, değil mi? Yani time to call back aslında
uygulama geri çağrısı üzerinde genel bir sarmalayıcıdır, burada IS bir
uygulama için belirli bir geri çağrıdır, oysa timeout underscore geri
çağrısı önceden tanımlanmış bir prototipe sahip genel bir geri çağrıdır.
Ve bu zamanlayıcı geri arama işlevinin kabul ettiği
argüman, geri arama işlevine aktarılan gerçek argümandır.
Yani burada, eğer buradan geçtiyseniz, doğruluk sıfır XP'dir, o
zaman yaşlı Lord Saville, PDR sıfır x FTE yükleyecektir,
değil mi? Şimdi teoriyi tartışmak için biraz daha
zaman harcayalım ve sonra zamanlayıcılarımızı şimdi uygulamaya başlayacağız.
İhtiyacımız olan bir sonraki şey, zamanlayıcının süresinin dolmasını belirtmenin bir yoludur.
Değil mi?
Öyle.
Zamanlayıcıyı başlattıktan sonra, nanosaniye kaç saniyedir?
Zamanlayıcımızın süresinin dolmasını veya ateşlenmesini istiyoruz.
Şimdiye kadar, gönderme standartları var, bize veri yapısını sağlayın I
timer's timorous back again ve muhtemelen duymadığınız yeni veri yapıları.
Dolayısıyla bu veri yapıları yalnızca zamanı belirtmek için kullanılır.
Bu veri yapısının tanımını görürseniz, yine sadece IT aralığını ve değerini
üyelere kısıtlar, değil mi? Bu iki it into well ve
it well, do üyeleri yine veri dışıdır, zamanları geri bağlar.
Şimdi destruct zamanlarının, pack veri yapısının tanımını görmemizin zamanı geldi, ki
bu yine iki üyeden oluşan bir koleksiyondan başka bir şey değildir.
İlk üye saniye cinsinden bir zamanı, ikinci üye ise nanosaniye cinsinden zamanı temsil eder.
Doğru.
Bu standartlar bize zamanlayıcının sona erme
süresini nanosaniye cinsinden belirleme olanağı sağlamaktadır.
Şimdi zamanlayıcının sona erme aralığını belirtmek için saygın
bir yapı olan bu öğenin nasıl kullanıldığını tartışalım.
Yani bu veri yapısını aşağıdaki gibi başlatırsam, bu IT değeri nokta TV'yi bozar.
Saniye beşe eşittir ve TV nanosaniyemiz sıfıra eşittir.
Değil mi? Bu basitçe zamanlayıcımızın süresinin
beş saniyeye ayarlandığı anlamına gelir.
Yani, zamanlayıcıyı başlattıktan sonra, tüm zamanlayıcılar beş saniyeye kadar ateşlenecektir.
Değerinin yaptığı şey budur, sona erme zamanlayıcısını ayarlamak,
zamanlayıcı için bu sona erme zaman aralığını ayarlamak,
yol boyunca zamanlayıcıyı gerçekten ne zaman uygulayacağımızı tartışacağız.
Doğru.
Bu yüzden bu konudaki tartışmayı daha sonraya bırakalım.
Böylece, zamanlayıcı için belirli bir sona erme zaman aralığına sahip olduğumuzda.
Şimdi geriye kalan son adım aslında zamanlayıcıyı devreye sokmak, yani zamanlayıcıyı başlatmaktır.
Değil mi? Bunun için, az önce yapılandırdığımız zamanlayıcının işaretçisini
hemen geçen bir API zamanlayıcı ayar zamanı verilir.
Ancak ikinci argüman şimdi üçüncü argümanı bu zamanlayıcı özelliklerinin adresi
olarak geçirdi ve bu kötü argümanı null olarak geçti.
Sıfır gibi pozitivitenin boş olduğunu söylediğim argüman daha fazla tartışmaya ihtiyaç duyuyor
çünkü amacımız zamanlayıcı tabanlı programların durum makinesi ile nasıl uygulanacağını anlamak.
Ayrıca, atladığımız argümanlar aslında isteğe bağlı argümanlardır ve Taimur'un
nasıl çalıştığını anlamak için zorunlu bir tartışma gerektirmez.
Şimdi bunun oldukça sıkıcı ve fazla olduğunu biliyorum, o yüzden tüm parçaları
bir araya getirelim ve zamanımızı veya demo programımızı doğru yapalım, değil mi?