WEBVTT 00:05.030 --> 00:10.040 So guys, in the previous lecture video, we discussed asynchronous mode of thread cancellation. 00:10.070 --> 00:14.930 Now let us discuss what are the problems with asynchronous mode of thread cancellation. 00:15.080 --> 00:15.860 Right. 00:15.980 --> 00:18.830 So let me ask you one simple question. 00:18.830 --> 00:24.710 What will happen if you are driving a car and suddenly you are asked to leave the steering wheel right? 00:24.740 --> 00:28.550 Suddenly may God forbid you would encounter an accident. 00:28.580 --> 00:30.320 The same applies here. 00:30.680 --> 00:36.770 When we say that the thread is cancelled asynchronously, it simply means that the thread can be cancelled 00:36.770 --> 00:39.710 at any point in its execution flow. 00:39.710 --> 00:46.310 And when the thread gets cancelled at any arbitrary point in its execution flow, it can lead to certain 00:46.310 --> 00:50.450 problems such as resource leaking, data structure, corruption. 00:50.450 --> 00:55.910 We call this data structure corruption with a technical term called invariance, and it may also lead 00:55.910 --> 00:56.930 to deadlocks. 00:56.960 --> 01:02.480 So now let us understand these one, two, three points one by one, with the help of an example to 01:02.480 --> 01:07.950 see that how asynchronous mode of cancellation of the threads can lead to these problems. 01:07.950 --> 01:10.320 So let us discuss the resource leaking. 01:10.770 --> 01:17.130 So if you notice the program that we just discussed and wrote in the last lecture video, so this is 01:17.130 --> 01:18.990 the thread function, right? 01:19.650 --> 01:25.530 And the thread which is executing in this function can be asynchronously cancelled right now. 01:25.530 --> 01:31.740 If you notice this thread usually span its most of the time in between line 55 to 61. 01:31.740 --> 01:32.400 Right. 01:32.400 --> 01:36.750 Because our slave threads are executing in infinite loop, right? 01:36.750 --> 01:43.860 So it simply means that when some other thread in our case it was the main thread send the cancelled 01:43.860 --> 01:47.130 signal to this thread which is executing in this function. 01:47.160 --> 01:50.490 The thread must be executing in any of these lines. 01:50.490 --> 01:53.460 That is from line number 55 to 60. 01:53.490 --> 01:54.150 Right. 01:54.150 --> 02:00.360 The thread could be executing at any line within this while loop when the thread receives the cancel 02:00.360 --> 02:01.110 signal. 02:01.410 --> 02:07.040 Now the question is that that when the thread receives this cancelled signal, the thread gets terminated. 02:07.050 --> 02:13.560 So do you see a problem here that when the thread gets terminated, our thread did not get the opportunity 02:13.560 --> 02:16.080 to actually close this file pointer. 02:16.110 --> 02:16.890 Right. 02:16.890 --> 02:19.740 So it is causing a resource leak. 02:19.860 --> 02:22.380 An open file is supposed to be closed. 02:22.380 --> 02:23.130 Right. 02:23.670 --> 02:30.420 Similarly, if you notice the argument of the thread was the thread ID and this argument was actually 02:30.420 --> 02:31.620 a heap memory. 02:31.650 --> 02:37.500 You can see that here was the thread ID that was allocated a memory, right. 02:37.530 --> 02:43.770 So it simply means that when the thread got canceled, the thread did not get any chance to clean up 02:43.770 --> 02:46.220 any memory which it was supposed to do. 02:46.230 --> 02:48.690 So it was causing a memory leak. 02:48.690 --> 02:49.500 Right. 02:49.620 --> 02:55.890 A thread is canceled, but this memory pointer was not freed, so it caused a memory leak. 02:56.490 --> 03:02.670 So this is the problem with respect to resource leaking that a thread which is being canceled in an 03:02.670 --> 03:08.220 asynchronous mode may leave some open file descriptors or sockets open forever. 03:08.220 --> 03:08.880 Right. 03:08.880 --> 03:15.780 And we have also seen that in our example we end up with leaking the memory when our slave thread got 03:15.780 --> 03:16.560 cancelled. 03:16.560 --> 03:17.280 Right? 03:17.690 --> 03:23.420 So this problem of resource leaking is addressed by using the concept of cleanup handlers. 03:23.720 --> 03:30.920 Cleanup handlers is all about giving a thread one last chance before it gets canceled so that the thread 03:30.920 --> 03:34.730 can clean up all the resources that it is supposed to clean. 03:34.730 --> 03:35.480 Right. 03:35.710 --> 03:41.800 Whereas the problem number two and three is handled by a concept of cancellation points. 03:41.810 --> 03:46.600 We will discuss these cancellation points when we will discuss the default cancellation. 03:46.610 --> 03:47.390 Right. 03:48.410 --> 03:54.380 So now that I have explained the point, number one, that why asynchronous mode of cancellation of 03:54.380 --> 03:57.380 the thread can subject to resource leaking. 03:57.380 --> 04:03.020 Let us discuss in the next lecture video that how asynchronous mode of cancellation of the thread can 04:03.020 --> 04:07.160 lead to data structure corruption or it can lead to deadlocks.