WEBVTT 00:05.900 --> 00:11.090 So guys, we had discussed that how asynchronous cancellation of the threads can lead to the problem 00:11.120 --> 00:12.480 of resource leaking. 00:12.500 --> 00:17.990 Now, in this lecture video, we will going to discuss that, how resource leaking can be 100% prevented 00:17.990 --> 00:21.020 in asynchronous mode of cancellation of threads. 00:21.620 --> 00:27.740 So if we could give a thread which is being canceled, one last chance to clean up all his mess. 00:27.770 --> 00:33.770 Now here mess means the memory, the open file descriptors, the open files, etcetera. 00:34.070 --> 00:37.190 Then resource leaking could be handled right. 00:37.190 --> 00:44.000 So it does make sense if the thread that is being canceled is given one last chance so that he can clean 00:44.000 --> 00:49.340 up all the resources that the thread has allocated, then resource leaking is prevented. 00:49.580 --> 00:54.680 So Posix standards provide the concept of thread cleanup handlers. 00:56.240 --> 01:01.520 Third, cleanup handlers are nothing, but they are special functions which are invoked just before 01:01.520 --> 01:03.410 the threat is about to cancel. 01:03.440 --> 01:04.160 Right. 01:04.460 --> 01:12.230 So when the threat T is delivered, the cancel signal, then just before the threat is terminated or 01:12.230 --> 01:13.190 canceled. 01:13.220 --> 01:16.730 These threat cleanup handlers are invoked. 01:16.910 --> 01:21.380 The threat cleanup handlers are a special functions, which is of this prototype. 01:21.380 --> 01:22.460 That is the threat. 01:22.460 --> 01:28.190 Cleanup handlers accept an argument which is of type Wordstar and they return a thing. 01:28.190 --> 01:28.940 Right. 01:29.120 --> 01:33.560 So this is actually a function pointer to the threat cleanup handler functions. 01:34.190 --> 01:39.080 When cleanup handler function returns, that is, they complete their execution. 01:39.080 --> 01:42.800 Then only after that, the threat is canceled immediately. 01:42.800 --> 01:43.520 Right. 01:43.880 --> 01:49.070 So what we will going to do is that we will going to extend our example, which we discussed last time. 01:49.070 --> 01:52.750 We have a file master slave, one async cancellation dot C. 01:53.000 --> 01:59.550 Now, in this file, we will going to implement this is the concept of threat cleanup handlers to derive 01:59.550 --> 02:05.310 the file master slave one async cancellation cleanup handlers dot C Right. 02:05.310 --> 02:11.280 So the second file is the solution which we obtained by implementing the thread cleanup handler solution 02:11.280 --> 02:12.450 on the first file. 02:13.110 --> 02:16.440 So we will going to look up and implement this file shortly. 02:16.440 --> 02:19.020 But let us complete the theory part first. 02:21.730 --> 02:27.370 So you can see in this slide that there is a thread function which is being executed in the context 02:27.370 --> 02:29.020 of some thread, right? 02:29.980 --> 02:37.930 There is some thread in the application which is doing its work by executing this function right. 02:38.470 --> 02:44.290 So thread cleanup handlers are specified in the form of a stack and this stack is nothing but it is 02:44.290 --> 02:45.670 a stack of functions. 02:45.880 --> 02:50.170 Cleanup handlers are invoked from top of the stack to bottom of the stack. 02:50.710 --> 02:54.880 So to set up the stack of thread cleanup functions. 02:56.400 --> 03:01.320 In the thread function, which is a function executed in the context of a thread. 03:01.350 --> 03:07.390 The very first thing that we need to do is to set up the stack of thread cleanup functions. 03:07.410 --> 03:11.190 We do so by invoking an API thread cleanup push. 03:11.370 --> 03:12.120 Right? 03:12.120 --> 03:19.530 The first argument to this API is a pointer to the cleanup function and the second argument is a pointer 03:19.530 --> 03:25.800 to the memory which will be supplied as an argument to this cleanup function when this cleanup function 03:25.800 --> 03:26.970 will be invoked. 03:27.000 --> 03:27.750 Right. 03:28.840 --> 03:34.780 So as soon as this particular line is executed, a stack is created internally. 03:34.780 --> 03:38.590 We call this stack as thread cancellation, clean up stack. 03:38.590 --> 03:39.190 Right. 03:39.190 --> 03:43.160 And the address of the function F one is pushed into this stack. 03:43.180 --> 03:50.020 Similarly, you can push more clean up functions into this stack by invoking p thread, clean up push 03:50.230 --> 03:52.510 API more number of times. 03:53.350 --> 03:58.840 So here you can see that after function F one, the function f two has been pushed into the stack. 03:58.870 --> 04:04.390 So function f two is at the top of the stack where function f one is at the bottom of the stack. 04:04.990 --> 04:13.240 So now it simply means that suppose at point P your thread gets cancelled as soon as your thread receives 04:13.240 --> 04:14.890 the cancelled signal. 04:15.190 --> 04:21.550 The functions which are present in this stack would be invoked one after the another, starting from 04:21.550 --> 04:24.530 the top of the stack towards the bottom of the stack. 04:24.550 --> 04:30.790 So the function F2 will be invoked and then function f1 will be invoked and then the thread will be 04:30.790 --> 04:31.600 cancelled. 04:31.600 --> 04:32.310 Right. 04:32.320 --> 04:35.800 So this is how this thread cancellation clean up stack work. 04:36.130 --> 04:42.190 The functions which are pushed into this stack are invoked whenever your thread receives the cancellation 04:42.190 --> 04:42.880 signal. 04:43.810 --> 04:50.170 And in case if the thread do not receive the cancellation signal and executes to the completion successfully 04:50.170 --> 04:55.450 without being cancelled, then it is the developer's responsibility to clean up this stack. 04:55.450 --> 04:56.170 Right? 04:56.870 --> 05:02.240 And when we say that we need to clean up the stack, it simply means that you need to pop out these 05:02.240 --> 05:03.770 functions out of the stack. 05:03.770 --> 05:09.410 So in order to pop out these functions, you need to invoke P thread cleanup pop API. 05:09.440 --> 05:10.100 Right? 05:10.100 --> 05:13.400 And you can pass zero as an argument to this API. 05:13.430 --> 05:19.460 I will discuss shortly that what does this argument does, but in order to pop out the function from 05:19.460 --> 05:22.820 the stack, you need to invoke this API with the argument. 05:22.820 --> 05:23.420 Zero. 05:23.420 --> 05:24.170 Right. 05:24.200 --> 05:27.660 This API simply removes these functions from the stack. 05:27.680 --> 05:33.980 In the last in first out order that is function f two will be removed first and then function f one 05:33.980 --> 05:35.840 will be removed after that. 05:36.350 --> 05:39.080 So pop the cleanup handlers from the stack. 05:39.110 --> 05:43.030 If thread function do not cancel and execute to completion successfully. 05:43.040 --> 05:43.670 Right. 05:43.670 --> 05:49.400 But in case if your thread receives the cancellation signal, then these functions are automatically 05:49.400 --> 05:55.400 invoked in the order in which they are specified in the stack from top to bottom as well as they will 05:55.400 --> 05:57.850 be popped out from the stack on its own. 05:57.870 --> 06:02.190 As a developer, you don't have to pop out these functions from the stack. 06:02.220 --> 06:06.210 In case if your thread receives the cancellation signal right. 06:06.630 --> 06:13.770 So now let us see a demo program in which we will going to exercise the concept of cleanup handlers. 06:14.760 --> 06:20.760 So in the next lecture video, let us extend the functionality of our same program so that our threads 06:20.760 --> 06:23.370 will now be able to handle resource leaking.