So, guys, now, in order to make the code changes, in order to demonstrate deferred cancellation,
what I will going to do is that I will take the last file that we edited and I will rename that file
as deferred cancellation dot C.
Right.
So now let me open this file and let us do the code changes such that my slave threads will going to
be cancelled using deferred cancellation approach.
So first of all, let us find out that what is the problem with this thread?
Cancellation.
Despite the fact that now we have the clean up handlers to take care of resource leaking right?
So using clean up handlers, we have addressed the problem of resource leaking, but still there is
a problem of invariants in this thread function.
Now what is the invariant problem here?
Uh, unfortunately, our program is very simple that we don't make use of link list or trees.
Kind of a data structure.
And I have explained in one of the previous lecture video that while performing the insert, delete
or update operations on those data structures may cause invariants.
If the thread updating those data structures is cancelled asynchronously.
Right.
But still, this program too suffers from the problem of invariants.
Now, with asynchronous mode of cancellation, we already know that the thread can be cancelled while
executing an instruction in its execution flow.
Right.
So if you take a look here that our thread calls the library function called as printf, and we know
that this function is internally used to format the string and write the formatted string into this
buffer, right?
Now, we don't know what is the internal implementation of this function, but there has to be some
internal implementation.
Right?
And let us suppose that the internal implementation of this function is 20 lines of code, right?
So it simply means that when your thread invokes this function, those 20 lines of code works behind
the scenes, right?
So it might be possible that if the thread cancellation signal is delivered to this thread, your thread
may choose to get cancelled while executing the internal implementation of this sprintf function.
Right.
And the same goes with the other functions or APIs which this thread calls.
Be it F right call or be it f flush call right now.
F Right Call is a special call here because it is not a normal function call, but in fact it is a system
call.
When I say system call, it means that the internal execution of this f write call would going to execute
in the kernel space.
So it simply means that if your thread choose to get canceled while executing an instruction which the
F write call is executing in the kernel space, then it may happen that your kernel may get corrupted.
Right?
It is very much possible that some logic was being executed in the kernel space and the abrupt cancellation
of the thread on behalf of which that logic was being executed.
And the abrupt cancellation of this thread may lead to some incomplete operation performed in the kernel
space which may ultimately lead to certain corruptions or could be anything in the kernel space.
Right.
So I would never want my this thread to get canceled at line number 74 or line number 75 at least.
Right.
These are the dangerous points where if the thread gets canceled, it may lead to any undefined behavior.
So therefore, in order to address the problem of invariants comes the concept of deferred cancellation
that we have already discussed.
I would want my thread to get cancel only at certain lines of code in my program and no other line of
code as simple as that.
As a developer, as a programmer, I want a complete control in my hand and I want to define that.
Okay.
I want my program to get canceled only at line number X, right?
Because I'm -- sure that if my program canceled at line number X, then problem of invariant would
not occur.
Right.
So currently our program make use of asynchronous mode of cancellation to convert it into deferred mode
of cancellation.
It would be very simple.
Simply you have to specify here p thread cancel deferred.
Right.
So now the cancellation type of the thread has been changed to the deferred cancellation.
Now coming to the cancellation point, let us suppose that every time your program wakes up from the
sleep, your program would like to test whether there is any pending cancellation signal or not.
So for that I would insert cancellation point at line number 78 in my program.
Right.
So I would insert p thread test, cancel API, call at line number 78in my function.
Right.
So every time the thread executes the line number 78, the thread will actually check if there is a
cancellation signal which is pending.
If there is a cancellation signal which is pending, then the thread will cancel right at line number
78.
Right.
So now as a developer, I have taken a control that if my thread cancels at all, it will cancel at
line number 78 only.
Right.
And therefore it would not cause any problem of invariant because rest of the calls in this function
say as print f and f right would execute completely and they would not be and their execution would
just not be canceled at any random point inside their implementation.
Right.
So note that whenever your thread canceled at line number 78, the cleanup handlers would work as usual.
So now you can compile this program and run this program and see that it works as per our discussion.
So now you can see that this is the thread function which is absolutely free from the problem of resource
leaking and the problem of invariants, right?
Now, there is no chance of any error whenever your thread executing this function gets canceled.
Right?
Our function is now fully thread cancellation safe.