In the last lesson, we took a look at what signals are and how we can send them to our processors, as well as discussing what signal handlers are and why we may want to use them.

In this lesson, we're going to talk a little bit more about one of the use cases when it comes to handling signals, specifically graceful shutdown or graceful termination.

Graceful shutdown is the process in whereby you intercept the signal interrupt, and rather than your application exiting as soon as the signal is received, it performs any tasks it needs to before then shutting down.

When it comes to, say, a web server, graceful termination would be handling any requests that are currently in flight, but preventing accepting any new ones from coming in. Then, once all of the requests are handled, the server itself would begin the process of shutting down, which would also mean terminating any database connections and cleaning up any resources.

In the case of a command line application, graceful shutdown isn't always needed, but there are some situations where it's warranted.

Take, for example, the code I currently have on screen. Here I have a simple main function, which is opening a file called lockfile, and doing so in a way that we can both create it, and only create it if it doesn't exist already. We'll take a deeper look at the open function, as well as the parameters we're passing in, in a later module.

However, for the meantime, just understand that we're creating the file due to this flag, and we're doing so exclusively, meaning we only create the file if it doesn't exist, and the file's name is lockfile.

Then, if we can't create the lockfile, we're printing out an error and returning early. Otherwise, we then add some deferred calls to both close the file and to remove it, as well as also sleeping for 10 seconds to simulate some work before exiting.

If we go ahead and run the code as follows, using the go run command, you can see now I have a lockfile created in the directory, and the process is running. If I try to run another process, you can see it says failed to create lockfile, another process might be running. Open lockfile, file exists, which is the error that we're receiving from the open command.

Now, my original command has finished, and the lockfile should no longer exist in the directory, which it doesn't. Which means I can run this command again, and the lockfile should be up and running. As you can see, this is what we're expecting. We only want one process to be running at a single time, and we're making use of the lockfile in order to achieve this, which is being cleaned up after the process has finished, and will allow any other process to continue.

This is a very similar concept to what we saw when it came to mutexes. However, rather than locking goroutines, we're instead locking processes through the use of a lockfile.

However, our code unfortunately has a bug. For example, if I go ahead and run this code again, using the gorun command, which creates the lockfile, as you can see, if I now send the signal interrupt using ctrl and c, it unfortunately causes the lockfile to still remain. This is an issue because now our system is in a bad state. If I try to run the gorun command again, the application will fail to start, because it can't obtain the lock on the lockfile, even though there's no actual process that has obtained the lock.

This is a bit of an issue, because we still want to be able to interrupt the signal, and in either case, we want our lockfile to be removed. Fortunately, we can solve this by making use of a signal handler, which we saw how to do in the last lesson using the notify function of the signal package. So let's go ahead and implement it.

To do so, we first need to create a channel, which we can do of make(chan os.Signal), and we'll set the buffer size to be 1, as follows. Then we can go ahead and call the signal.Notify function, passing in our channel, and passing in the signals we want to listen for. In this case, let's just listen for the interrupt.

Now, with our signal defined, we can go ahead and listen for it, ensuring that we clean up our resources in case we receive a signal. But how to do so? Well, if we go ahead and just call listen on the ch as follows, then if we go ahead and run our code, first we need to remove the lockfile. Now, if we go ahead and run our code as follows, you can see the process is running and no other can, but our application won't exit, even after 10 seconds. Not until we send the signal interrupt. As you can see, it now exits.

This is also an issue if we try to interrupt the code sooner. So if I press CTRL C before 10 seconds, you'll see that it's not actually cancelling, and will only do so once the 10 seconds has been met. This is not how we want our code to work. Instead, we want it to be able to cancel as soon as we see a signal interrupt, or in the event that a time.Sleep occurs.

So in order to solve these issues, let's begin by making it so that whenever we press CTRL and C, our application will exit, even if the time.Sleep hasn't yet completed. So to do so, let's go about wrapping our time.Sleep inside of a go function as follows. And we can go ahead and call this as so. Now, if we go to run this code, you can see pressing CTRL and C will cause the application to quit immediately. However, our application won't actually exit after the 10 seconds, unless we press CTRL and C. Although that was only 9 seconds, so let me wait for 10 seconds to see this in action. 1, 2, 3, 4, 5, 6, 7, 8, 9, 10. We'll do a couple more just for good measure. 12 seconds.

As you can see, the application didn't exit on its own. Therefore, we need to add in an implementation so that our code only waits for either the channel to be done, or to also wait for the work to be done as well, exiting if either one of those conditions is true.

Fortunately, we've already seen how to do this back when we looked at concurrency, which was when we were selecting over two multiple channels at the same time. Therefore, to do this, we can go ahead and use a second channel in order to notify the main thread that the work has been completed. A common pattern to do this in Go is to use something called a done channel, which is defined as follows, which I'm using the make command of a chan struct{}. You can use a boolean here, but the empty struct is going to be more efficient, as we don't want to pass any data onto this, but instead we just want to close this channel when we're done, which we can do using the following deferred statement.

Then inside of the section where we're waiting for a channel, we can just use a select, as we've seen before, waiting on either the signal channel to be done, or the done channel to be done. In either case, we'll just exit our code as follows. Now, if we go ahead and run this code, we should see after 10 seconds the application exit, which it does, and the lock file has been removed.

Additionally, if we also use the go run command again, and if I press control and C, the application exits instantly. Not only this, but in both cases our lock file was successfully removed, meaning no matter if we send a sig int, or if the application exits on its own terms, it won't cause our system to be left in a bad state.

So with that, we've managed to add in graceful termination to our code. And whilst using a done channel is one approach to do so, it's not the only approach we could have taken. In fact, there's a number of different approaches you can take when it comes to listening for a channel and performing cancellation.

In the next lesson, we'll take a look at some of these different strategies in order to handle cancellation of long-running tasks, specifically when it comes to working with channels. And after we've taken a look at those strategies, we'll be introduced to another type that handles cancellation even better.