In the last lesson, we made use of a signal handler in order to perform graceful shutdown of our application code, specifically ensuring that a lock file we were creating was being removed even when the signal interrupt was sent to our application. We achieve this through making use of what's known as a done channel, closing it once our application had finished processing, or in this case, sleeping for 10 seconds.

In Go, done channels are a pretty common construct, and they work in a very similar way to weight groups. However, unlike weight groups, they have the added benefit of being able to be used in conjunction with other channels, through the use of the select keyword. Because of this, it means you can listen to both the done channel and any other events on other channels as well, allowing you to exit your code when at least one condition is met. In our case, our code is exiting if our application happens to receive the signal, or if the work happens to be completed, which in this case is 10 seconds passing.

However, whilst the use of a done channel is a common construct, it's not the only way you can perform graceful termination, and in some cases, it's actually not the most optimal way, depending on what your situation looks like. To show what I mean, here I have another example of some graceful termination, or shutdown, which currently makes use of a signal listening to the os.interrupt again.

This code generates a number of events, which have the following struct, which have the following definition, basically just being a struct that contains an integer, of which the struct has the following process method, which again is simulating some work taking place, so we're sleeping for about a second. The idea behind this is perhaps the event is doing some external processing, such as fetching data from a database, doing some form of transformation on that data, and then writing it to another data sync.

In any case, we're simulating this behaviour by sleeping for one second. The code is very simple. All it does is creates a signal to notify on signal interrupt, generates all of the events, of which there are 10 in total, and then calls the processEvents function, passing in the signal, as well as the events we want to process. Then inside of this code, we're making use of a done channel, so we can notify when the actual processing is complete.

Then inside of a go routine, we're looping over each of the events and calling the process method, which if you'll remember, sleeps for one second. Then at the end of this process function, we're selecting over both the done channel, so when the events have been finished completing, which will be fired with the following defer to close, and also listening for any signals that we receive on our signal channel.

If I quickly go ahead and run this code using the go run command, you can see it will process through each event, as well as logging the current events being processed, as well as when it's complete, and then after 10 events we should see the application shut down, and we get the message saying all events processed, finishing. If I go ahead and run this code again, using the go run command, and if we go ahead and kill this using the pkill command with the sigint number, which is number two.

By the way, this command works very similar to what we were using before, which was kill -2, and then passing in the pgrep to get the process identifier. The pkill command is basically a combination of these two. So it performs a pgrep on the actual process name, sends the signal interrupt, which is -2, and we'll call the kill command on it. It's a really nice, simple way to do basically what we were doing in the last lesson.

In any case, as you can see, we receive the signal interrupt, or sigint, and we end up shutting down. Whilst this code works to shut down whenever we see a signal interrupt, or when the events are processed, it currently doesn't have what I would consider graceful termination. This is because, if you take a look at the order of events, you can see for each event that we do complete, we begin it and then complete it. However, for event ID number 6, whilst we start processing the event, as soon as we receive the signal we shut down, before the event has completed processing.

In the worst case, with our code exiting in the middle of a processing function, we could be leaving our system in a bad or partial state, such as if we were writing data to two different data stores and our code was shut down in the middle of those two writes. Most of the time, you should be designing systems with that sort of fault tolerance in mind. But even then, in the best case, we could have done some heavy processing and all of that would be wasted, and we would have to do it again when our application starts back up. Therefore, it would be a little nicer if we could make it so that our code exits once the current event has been processed, rather than exiting in the middle of an event.

This is another cancellation strategy that we can actually apply - one that doesn't actually make use of a done channel, and is rather simple to implement. So, let's go ahead and implement this strategy, where we wait for an event to finish processing if one is currently in flight, before allowing our process to shut down.

To do so, let's go ahead and get rid of all of the code that we currently have inside of our processEvents function, just to start from a clean slate. Then, the first thing we want to do is iterate over each of our events, which we can do using the following for range expression. So, for each event in range of events, then we'll perform some processing. Before calling the event.process method, the first thing we want to do is check to see whether or not we had an event on our channel.

However, we can't just do this by using the following expression, as this code will block until we receive a signal, and in that case we actually want to exit before processing a new event. Instead, we need to make use of the select keyword, and we need to add in a case in order to handle our channel as follows. Then, if we do see that we've received an event on the channel, we just want to return early.

Next, in the case that we don't have anything on our events, we then want to go ahead and actually process. However, if we try to call the event.process outside of this select statement, you'll see that we receive unreachable code. This is because the select statement will wait for any of its cases to return true, or for an event to be sent on to one of the channels before it proceeds, which means this will block until, in this case, we only receive an event on the os.channel.

It's basically no different from doing ch <- return. Therefore, we instead need a way to say if none of the cases are true, then fall through to a default case. Which we can do, similar to using, say, a switch statement, which is by adding in the default keyword. This defines a block of code that should take place if none of the channels have events on them. Then, inside of this default case, let's go ahead and call the process method of our event.

Now, the flow of this is basically for each event that we iterate through, we're calling the following select statement to see whether or not our signal channel has any signals on it, in which case we'll then return early. Otherwise, we fall to our default case where we go ahead and process our event. Then, once the event processing is complete, we go back to the start of our loop and begin the select case once again.

To see how this looks, if we go ahead and run the code again, I'll get a pkill command ready to go, and if we call the go run command as follows. Now, if I go ahead and send this after number three has started, you can see that our code doesn't exit until the third event has been completed.

To show this in a little more action, if we go ahead and use the control C, which we'll print out to the console as well, and we'll do it for three. You can see control C was entered, but the application didn't exit until we received the complete event. Let's go ahead and put some print line logic here as well, just to make it a little easier to see. SIGINT received, exiting, and we'll go ahead and do a format.Println, all events processed.

Now, if we run this again, and we'll wait till now, you can see that we did complete event number two, but we still received the SIGINT, so we were exiting. And if we just go ahead and run this for 10 seconds, we should see all of the events iterate through and begin and complete, and then we'll get our logline letting us know that all of the events were processed, which is the case.

With that, we've managed to take a look at another strategy for graceful termination when it comes to iterating through a number of events. In this case, it allows us to fully process an event before we exit, which can help to prevent our system from being left in a partial state, or in the most mildest of cases, prevent us from wasting CPU cycles.

However, this isn't the only way you can perform graceful termination or handle multiple channels. For example, if you'll remember, back when we started looking at long running tasks, we were using the PING command to show an example of a long running task. If we take a look at the PING command in more detail, you'll see what's happening is it's sending an event once every second, and then when we're pressing Ctrl+C, it's cancelled.

And then when we're pressing Ctrl+C or sending SIGINT, the events stop working. So how would we go about implementing something similar to this when it comes to our own code? To show how this works, here I have another example. This time it's replicating the PING command. If I go ahead and run it quickly, parsing in the host of google.com, you can see it operates in a very similar way, although it doesn't actually send any packets to Google.

As you can see, this is printing out PING google.com every one second, and does so pretty consistently. We're achieving this using a similar methodology to what we saw when it came to event processing, where we're iterating infinitely and performing a select statement, checking to see if we've received a signal on the channel, and if not, we're calling PING and then sleeping for time.Second.

Whilst this does work, if I go ahead and press Ctrl+C, you'll see there's always up to a second delay before we exit, which in this case isn't actually what we want. Whilst a single second isn't too bad, if we had set this to be 5 seconds, then this would actually be a bit of a nuisance. If I go ahead and run this code now, parsing in again, google.com, you'll see if I press Ctrl+C, it would take up to 5 seconds for the application to exit, which in this case is a little more unacceptable.

Instead we'll want to exit straight away, provided we have the ability to do so, which in this case we do, as we're not actually doing any work, we're just sleeping until we perform the next ping event. Fortunately we can make use of channels to solve this, specifically the channels provided by the time package, of which there are a couple.

As you saw we're currently using the time.Sleep function, which is causing us to wait until the sleep expires before we can move on. Instead of this, we can actually use the After channel, which, similar to the Sleep function, waits for the passed in duration. However, rather than blocking the go routine like the sleep function does, it instead returns a channel, which means we can go ahead and add it as a case inside of our select statement.

So let's go ahead and use this, adding in a case of time.After and we'll do time.Second * 5. Then we can go ahead and get rid of the time.Sleep in the default case and instead log out printline PING inside of this time.After. Now if I go ahead and run this code again using the passing in google.com, you can see whilst the ping doesn't appear straight away, which is an issue with this implementation we would have to ping before we entered our for loop.

You can see it is still pinging every five seconds. However, the difference here is after the next ping, if I press CTRL and C, you'll see we exit immediately, allowing us to also perform some graceful termination. This is because rather than the default case, which will automatically be selected when no channels have events on them, instead our select statement is blocking until either of the two channels have an event.

This means that once we send SIGINT, then this channel has an event and it exits immediately. But until that happens, as soon as there is an event on the time.After channel, which is after five seconds, then our ping log is printed out. At this point you may be wondering, well what happens if there's an event on both channels at the same time? And whilst it's improbable, it is possible.

Well, in that case the select statement will randomly choose between the two, using an internal pseudo-random generator, and so therefore it could be either which one takes place. For some situations that may not be preferable. Unfortunately, it is a caveat of how the select statement works. In any case, using the time.After is a pretty great construct if you want to be able to wait a certain number of seconds, but also have it as a channel so you can select over it in conjunction with other channels.

However, the time.After does have a bit of a caveat. For instance, if I go ahead and set this back to be one, and then let's say we are doing some work here, which can take around half a second. So we'll do a time.Sleep of 500 * time.Millisecond. So we're sleeping for half a second just to again simulate some work. If I go ahead and run this code, take a quick look at the timestamps of each log output. You'll see, rather than this happening every second, there's now some drift.

This is caused because we now have some processing time that's going on in between each iteration of our for loop, which is causing our code to slowly drift due to the amount of time it's taking to process. So in each iteration it's taking about a second and a half, which means it's sometimes populating as there being a two second gap between each ping. In some situations this is absolutely fine. However, when it comes to our ping command, we really want to ping once every second.

So how do we go about doing this? Well, if we take a look at the time package yet again, you can see here we have the Tick function, which is actually very similar to the After function in that it takes a duration and returns a channel of time, but it provides a more consistent timer that will tick continuously until it's actually cancelled. If we take a look at the documentation, there were some changes made in the most recent version of Go, 1.23.

This is because there were situations that the ticker would never be recovered by the garbage collector, which means it would be somewhat inefficient when it came to your code's memory. In this case it said it should use the new ticker method instead, which if we take a look at the type of ticker you can see here's the NewTicker function, and would also have to use the Stop method in order to turn off a ticker.

However, since Go 1.23 an improvement has been made to the language where the garbage collector will recover any unreferenced tickers, even if they haven't been stopped, so we don't have to worry too much about using this type. In any case, let's replace our call to time.After with a brand new ticker, which we can define as ticker = time.NewTicker. You can also just use the Ticker function, and we'll pass in time.Second as well.

Then rather than casing on time.After, we can replace on the C field of the ticker, which returns a channel of time.Time. Now if I go ahead and run this code again, you can see this time even though we have the time.Sleep of 500 milliseconds for each tick, our ticks are still consistent, and we don't have any drift. As you can see we're ticking each second regardless of how much time it takes for us to actually tick.

Of course if this was over one second then we would start seeing some drift, but this is also true of the case of the PING command as well. For instance, if we take a look at this you can see there is now some drift happening because we are exceeding the time.Second, although in that case if we wanted to make sure that we were consistently ticking we would probably just use a go routine as follows.

And now if we go ahead and cancel this you can see that this case we would now be ticking once every second although it would still be multiple go routines going at the same time. If you happen to have long running tasks that may exceed your time.Ticker and you need that tick to be consistent then using a go routine is going to be the best approach.

In any case with that we've managed to take a look at some other strategies of how we can perform graceful termination depending on what our system requires. However you may be wondering which strategy to use at which point. Well most of the time it really depends on the requirements of your code. If you happen to have a big piece of work that can't be broken up into smaller chunks then using a done channel is probably going to be the right approach.

Or if you happen to have an application like the PING command like we saw before where it needs to periodically work every minute, every second or every hour then using the time.After or time.Tick is going to be the right approach. However if you just want to be processing over multiple events or you can break up your tasks into smaller subtasks then using an iterator and checking to see if the channel has been fired on each event or before processing each event is going to be the most optimal approach.

Most of the time when it comes to concurrent code you'll actually be performing something very similar to this processEvents. Even if it's not iterating over events but let's say you're going to send a request and you'll check the channel handle result and you'll check the channel here and you'll break at each of these individual points. However, rather than using a channel to do this Go actually provides a much better type called context.Context which provides a lot of functionality to handle cancellation across multiple go routines in what's known as structured concurrency.

In fact that's actually what we're going to take a look at in the next lesson the context.Context type and how we can use it when it comes to cancellation within our code.