WEBVTT

1
00:06.780 --> 00:11.940
Şimdi, genellikle bir zamanlayıcı
oluşturduğumuz Create API zamanını
tartışalım.

2
00:12.690 --> 00:16.820
Şimdi zamanlayıcının yaratılışıyla ilgili
bazı teorileri tartışalım.

3
00:17.280 --> 00:24.120
Zamanlayıcılarımızı uygularken işleri
hızlı bir şekilde görebilmemiz

4
00:24.120 --> 00:24.780
için mümkün olduğunca çok askeri kapsamak
istiyorum.

5
00:25.260 --> 00:29.550
Hızlı bir şekilde klavyeye basmaya
geçebilir ve işleri eylem halinde
görebiliriz.

6
00:30.180 --> 00:34.290
Bu yüzden bu sefer etrafımızda
oluşturduğumuz bu API ile başlayacağız,
değil mi? Bu

7
00:36.080 --> 00:41.540
API'nin üç argüman kabul ettiğini
görebilirsiniz, ilk argüman şu anda
oluşturduğunuz zamanlayıcı

8
00:41.540 --> 00:48.320
türüdür Linux işletim sistemi Politika
API'miz farklı türde zamanlayıcılar
oluşturmanıza izin verir.

9
00:48.830 --> 00:56.240
Bu nedenle, farklı zamanlayıcı türlerinin
tartışılmasının aslında burada çok değerli
olmadığını düşünüyorum.

10
00:56.990 --> 01:03.290
Bu yüzden size gerçek zamanlayıcı türünü
uygulayarak göstereceğim çünkü başka
zamanlayıcı türleri

11
01:03.290 --> 01:10.040
de var, ancak bu zamanlayıcılar o kadar
yaygın olarak kullanılmıyor ve çoğu

12
01:10.040 --> 01:15.680
senaryoda uygulamalarını garanti eden
zamanlayıcı türü en yaygın dağıtımlarda
gerçek zamanlayıcılardır.

13
01:17.560 --> 01:23.260
Dolayısıyla, ayrıştırmamız gereken ilk
argüman sabit değerdir, bu

14
01:23.260 --> 01:24.610
da bunu temsil eder, ne tür bir zaman

15
01:25.570 --> 01:32.890
oluşturmak istiyorsunuz? İkinci
parametreler aslında geliştiricinin veya
programcının

16
01:32.890 --> 01:34.150
zamanlayıcıları kontrol eden çeşitli
parametreleri belirtmesine olanak tanır.

17
01:34.540 --> 01:34.930
Değil mi? Bu parametrelerin ne olduğunu
birazdan ayrıntılı olarak

18
01:35.830 --> 01:39.130
tartışacağız. Ve üçüncü argüman
zamanlayıcıya bir işaretçidir, değil mi?

19
01:39.430 --> 01:42.700
API başarı durumunda sıfır yazar, aksi
takdirde hata durumunda

20
01:45.630 --> 01:52.560
eksi bir döndürür ve global değişken hata
numarası

21
01:52.560 --> 01:55.920
ne tür bir hata oluştuğunu göstermek için
ayarlanır.

22
01:56.280 --> 02:00.570
Şimdi bu global değişken hata dosyasında
tanımlanmıştır, şüphesiz edge.

23
02:00.870 --> 02:06.150
Ve bu sayıyı her zaman belirtilen
yüzdeleri kullanarak

24
02:08.200 --> 02:15.250
yazdırabilirsiniz, değil mi? Yani şimdi
büyük geri

25
02:15.250 --> 02:15.520
dönüşlerin zamanı eksi bir, bu hatayı
yazdırarak

26
02:15.520 --> 02:16.360
hataya neyin neden olduğunu
görebilirsiniz? Değişken yok.

27
02:17.460 --> 02:23.190
Şimdi, zamanlayıcının bu kontrol
parametrelerini tartışalım, bu nedenle
zamanlayıcının bu kontrol

28
02:23.190 --> 02:27.080
parametreleri bir veri yapısı olan SIG
olayı ile temsil edilir.

29
02:27.420 --> 02:27.810
Doğru mu? Şimdi, yapıların durumu içinde,
değerini

30
02:29.370 --> 02:35.310
belirtmemiz gereken üç üye vardır, ilk

31
02:35.310 --> 02:38.610
üye bir SIG evey bildirim işlevidir.

32
02:39.030 --> 02:45.440
Yani, zamanlayıcı sona erdiğinde buraya
aktarmamız gereken zamanlayıcı geri arama
işlevi işaretçisidir.

33
02:45.480 --> 02:48.810
Çağrılacak olan bu işlevi yapar, değil mi?

34
02:49.110 --> 02:54.960
Ve bu fonksiyon çağrılacağı zaman, bu
fonksiyona

35
02:54.960 --> 02:55.680
bazı argümanları duraklatmak için de ses
çıkarır.

36
02:56.100 --> 03:00.840
Bu argüman, bu veri yapısının ikinci bir
parametresi tarafından belirtilir.

37
03:02.860 --> 03:07.540
Bu hasta ortam değerlidir, sinyal değeri
işaretçisi değildir.

38
03:07.840 --> 03:08.200
Doğru.

39
03:08.500 --> 03:15.220
Ve bu üye, bu zamanlayıcı geri çağırma
işlevine bir

40
03:15.220 --> 03:16.780
argüman olarak ayrıştırılacak olan bellek
yığınının adresini gösterir.

41
03:17.170 --> 03:17.530
Doğru.

42
03:19.300 --> 03:26.320
Bu nedenle, bellek ayırmak ve ilgili
verileri ve bu belleği yerleştirmek ve bu

43
03:26.680 --> 03:34.570
EVP veri yapılarının bu belirli üyesini bu
bellek adresiyle başlatmak uygulamaların
sorumluluğundadır.

44
03:34.840 --> 03:35.200
Doğru mu? Üçüncüsü, IGB Bildirim üyesi her
zaman AIG

45
03:38.040 --> 03:46.790
gibi bu sabite kodlandığından, bu sabiti
belirterek tehdidin altını

46
03:46.840 --> 03:55.050
çiziyoruz, aslında albaydan bir zaman
başlatmasını veya zamanı çağırmasını

47
03:55.260 --> 03:57.210
veya geri çağırmasını istiyoruz, değil mi?
Aslında albayın geri

48
03:58.850 --> 04:04.970
arama işlevini yürütebileceği başka yollar
da vardır, zamanlayıcının

49
04:04.970 --> 04:09.080
süresinin dolması gerekmez, ancak başka
şekillerde de çağırabilir.

50
04:10.100 --> 04:16.670
Burada tartışmak için önemli olmayan diğer
yollar nelerdir

51
04:18.170 --> 04:20.600
çünkü şu anda bu geri arama işlevine gelen

52
04:21.050 --> 04:24.440
zamanlayıcılarla uğraşıyoruz? Bu geri
çağırma fonksiyonunun prototipi veya

53
04:24.950 --> 04:26.720
imzası ne olmalıdır? Bir prototipi olmalı,
değil mi?

54
04:27.260 --> 04:33.770
Yani bu geri çağırma fonksiyonunun
prototipi sabittir

55
04:33.770 --> 04:35.360
ve bu fonksiyon silinmiş hiçbir şey
döndürmemelidir.

56
04:36.260 --> 04:40.280
Ve bu fonksiyonun argümanı bir veri tipi
union signal'dır.

57
04:40.700 --> 04:50.660
Şu anda, Union Signal gibi bu yeni veri
yapılarının SIG olayı olduğunu

58
04:50.660 --> 04:57.890
duymanın biraz tedirginlik yaratma
eğiliminde olan bir şey olduğunu
anlıyorum, ancak bu

59
04:57.890 --> 05:02.380
veri yapılarının kullanımı çok basit
değil, örneğin ve veri yapıları bile
arayın.

60
05:02.390 --> 05:05.450
Tek yapmanız gereken bu üç üyeyi
başlatmaktır.

61
05:05.570 --> 05:05.930
Öyle değil mi? Benzer şekilde, Union

62
05:06.350 --> 05:09.260
SIG için de yapılar vardır.

63
05:09.260 --> 05:15.920
Tek yapmanız gereken yüksek değerli bir
işaretçi olan bu üyeye erişmektir, değil

64
05:17.680 --> 05:22.570
mi? Yani aslında, yosun noktası,
belirttiğim gibi, bu argümanın adresiyle
aynıdır.

65
05:22.930 --> 05:23.290
Değil mi? Çünkü günün sonunda amacımız, bu
argümanla temsil edilen

66
05:23.740 --> 05:30.940
kullanıcı tanımlı veri yapılarıyla belirli
bir geri çağırma işlevi olan

67
05:30.940 --> 05:37.390
uygulamayı çağırmaktı, değil mi? Yani time
to call back aslında

68
05:39.130 --> 05:45.550
uygulama geri çağrısı üzerinde genel bir
sarmalayıcıdır, burada IS bir

69
05:45.550 --> 05:51.520
uygulama için belirli bir geri çağrıdır,
oysa timeout underscore geri

70
05:51.520 --> 05:52.210
çağrısı önceden tanımlanmış bir prototipe
sahip genel bir geri çağrıdır.

71
05:54.120 --> 06:02.230
Ve bu zamanlayıcı geri arama işlevinin
kabul ettiği

72
06:02.230 --> 06:03.930
argüman, geri arama işlevine aktarılan
gerçek argümandır.

73
06:06.170 --> 06:15.020
Yani burada, eğer buradan geçtiyseniz,
doğruluk sıfır XP'dir, o

74
06:15.020 --> 06:17.720
zaman yaşlı Lord Saville, PDR sıfır x FTE
yükleyecektir,

75
06:18.710 --> 06:23.600
değil mi? Şimdi teoriyi tartışmak için
biraz daha

76
06:23.600 --> 06:26.330
zaman harcayalım ve sonra
zamanlayıcılarımızı şimdi uygulamaya
başlayacağız.

77
06:26.330 --> 06:30.350
İhtiyacımız olan bir sonraki şey,
zamanlayıcının süresinin dolmasını
belirtmenin bir yoludur.

78
06:30.590 --> 06:30.950
Değil mi?

79
06:31.310 --> 06:31.790
Öyle.

80
06:31.790 --> 06:35.570
Zamanlayıcıyı başlattıktan sonra,
nanosaniye kaç saniyedir?

81
06:35.870 --> 06:38.870
Zamanlayıcımızın süresinin dolmasını veya
ateşlenmesini istiyoruz.

82
06:41.170 --> 06:47.710
Şimdiye kadar, gönderme standartları var,
bize veri yapısını sağlayın I

83
06:47.710 --> 06:50.910
timer's timorous back again ve muhtemelen
duymadığınız yeni veri yapıları.

84
06:51.730 --> 06:55.330
Dolayısıyla bu veri yapıları yalnızca
zamanı belirtmek için kullanılır.

85
06:56.170 --> 07:02.950
Bu veri yapısının tanımını görürseniz,
yine sadece IT aralığını ve değerini

86
07:02.950 --> 07:04.930
üyelere kısıtlar, değil mi? Bu iki it into
well ve

87
07:07.020 --> 07:12.690
it well, do üyeleri yine veri dışıdır,
zamanları geri bağlar.

88
07:13.900 --> 07:20.140
Şimdi destruct zamanlarının, pack veri
yapısının tanımını görmemizin zamanı
geldi, ki

89
07:20.140 --> 07:23.890
bu yine iki üyeden oluşan bir
koleksiyondan başka bir şey değildir.

90
07:24.940 --> 07:30.490
İlk üye saniye cinsinden bir zamanı,
ikinci üye ise nanosaniye cinsinden zamanı
temsil eder.

91
07:30.760 --> 07:31.110
Doğru.

92
07:32.020 --> 07:40.450
Bu standartlar bize zamanlayıcının sona
erme

93
07:40.450 --> 07:41.710
süresini nanosaniye cinsinden belirleme
olanağı sağlamaktadır.

94
07:42.990 --> 07:50.280
Şimdi zamanlayıcının sona erme aralığını
belirtmek için saygın

95
07:50.280 --> 07:51.090
bir yapı olan bu öğenin nasıl
kullanıldığını tartışalım.

96
07:52.680 --> 08:01.160
Yani bu veri yapısını aşağıdaki gibi
başlatırsam, bu IT değeri nokta TV'yi
bozar.

97
08:01.320 --> 08:07.650
Saniye beşe eşittir ve TV nanosaniyemiz
sıfıra eşittir.

98
08:08.010 --> 08:08.400
Değil mi? Bu basitçe zamanlayıcımızın
süresinin

99
08:11.360 --> 08:16.370
beş saniyeye ayarlandığı anlamına gelir.

100
08:16.790 --> 08:21.440
Yani, zamanlayıcıyı başlattıktan sonra,
tüm zamanlayıcılar beş saniyeye kadar
ateşlenecektir.

101
08:22.640 --> 08:29.300
Değerinin yaptığı şey budur, sona erme
zamanlayıcısını ayarlamak,

102
08:29.300 --> 08:35.180
zamanlayıcı için bu sona erme zaman
aralığını ayarlamak,

103
08:35.180 --> 08:35.570
yol boyunca zamanlayıcıyı gerçekten ne
zaman uygulayacağımızı tartışacağız.

104
08:35.870 --> 08:36.230
Doğru.

105
08:37.430 --> 08:40.130
Bu yüzden bu konudaki tartışmayı daha
sonraya bırakalım.

106
08:42.710 --> 08:46.250
Böylece, zamanlayıcı için belirli bir sona
erme zaman aralığına sahip olduğumuzda.

107
08:46.430 --> 08:52.710
Şimdi geriye kalan son adım aslında
zamanlayıcıyı devreye sokmak, yani
zamanlayıcıyı başlatmaktır.

108
08:53.000 --> 08:53.360
Değil mi? Bunun için, az önce
yapılandırdığımız zamanlayıcının
işaretçisini

109
08:53.720 --> 09:01.100
hemen geçen bir API zamanlayıcı ayar
zamanı verilir.

110
09:01.760 --> 09:08.600
Ancak ikinci argüman şimdi üçüncü argümanı
bu zamanlayıcı özelliklerinin adresi

111
09:09.200 --> 09:11.540
olarak geçirdi ve bu kötü argümanı null
olarak geçti.

112
09:11.930 --> 09:18.140
Sıfır gibi pozitivitenin boş olduğunu
söylediğim argüman daha fazla tartışmaya
ihtiyaç duyuyor

113
09:18.140 --> 09:23.180
çünkü amacımız zamanlayıcı tabanlı
programların durum makinesi ile nasıl
uygulanacağını anlamak.

114
09:24.080 --> 09:30.950
Ayrıca, atladığımız argümanlar aslında
isteğe bağlı argümanlardır ve Taimur'un

115
09:30.950 --> 09:34.700
nasıl çalıştığını anlamak için zorunlu bir
tartışma gerektirmez.

116
09:36.370 --> 09:42.010
Şimdi bunun oldukça sıkıcı ve fazla
olduğunu biliyorum, o yüzden tüm parçaları

117
09:42.010 --> 09:44.110
bir araya getirelim ve zamanımızı veya
demo programımızı doğru yapalım, değil mi?