- So our next basic and our last basic channel pattern here
is wait for finished.
And wait for finished is going to show us
how we can signal without data.
Now I just want to make it clear that
what I'm showing you
would really be better served with a wait group.
A wait group began as a way of kind of doing
a signaling without data for that type of orchestration
and would be cleaner here
but I'm going to show you and walk through this code
just so you can see the mechanics.
Again, I'm going to want to stress that.
A wait group would make this code cleaner
but I need to show you the mechanics
so later on when we talk about
cancellation and deadlines with the context package,
it'll give you a little bit more sense.
Now look on line 75.
We're using the make again,
channel empty struct and it's unbuffered.
So we have an unbuffered channel which means guarantees,
except that the data type isn't string here,
it's the empty struct.
And we're going to use the empty struct
to denote from a code readability, signaling without data.
Since the empty struct is about no data,
we're going to use this.
And that basically means that
all we're really going to be doing is closing the channel
and there's no real guarantees with this
as I'm going to show you.
But anytime you see a make chan empty struct,
now we're going to be thinking, signaling without data.
We're going to turn the lights off.
Now, let's go back and look at what we're doing.
We are the manager, here we are
and we're running in our path of execution
and right away we go and we launch that
employee path of execution or go routine.
And once we do that again,
we're asking this go routine to do some work.
So they already know what they're supposed to do.
So now we come back and end up right there on line 83.
Notice again on line 83, we're doing a channel receive.
This is very similar
to what we were just doing before, right?
And here we go on the channel receive,
which means we're now in a blocking call, right?
We're right here blocking
because we're in our channel receive operation.
Now I want you to notice something
about the channel receive operation.
Up until now, all I've done is allowed you to see
that we can receive the value that's being sent.
But when we talk about cancellation and deadlines
or signaling without data, there is no data to receive.
And that's why what you're seeing is
the second form of the channel receive.
You can always get data out of it
if you're signaling with data,
but we can get a second flag, which is a buoyant flag,
that I use WD for, with data.
This is my with data flag
and it's a part of the signaling mechanics.
And what it's telling me is
that if I receive successfully off this channel
and the with data flag is true, then I have data.
We signaled with data.
But if the with data flag is false,
then we receive because the channel is closed,
because the lights are out.
Now I don't really need to store this variable,
I just wanted to display it on the screen
if you decided to run this.
Ideally in these scenarios,
we're probably doing nothing more than this,
which is I'm just going to block on the receive
and I don't care what comes out of it.
But what we're doing,
I'm just showing you the with data flag.
So here we are right, like we talked about here,
I'm blocked right now waiting, waiting.
How long am I waiting?
I don't know, it's unknown because we're signaling
even if it's signaling without data,
we're signaling with guarantees here right?
I have no idea how long we're going to be waiting.
Eventually the work finishes
and this time what happens is once the work finishes,
we don't signal with data,
on line 79, we close the channel.
What we now do here is close the channel.
We're turning the lights off.
Now when we close the channel,
that close is going to happen nano seconds
before the receive.
It's kind of like the send happens before the receive,
this time the close happens.
So the close is going to complete first
and then we're going to be able to move on second.
So that channel receive will immediately unblock
once the close operation is done.
So the close is going to happen before the channel receive
but what we've kind of done is just said
the work is done and you don't need anything
so turn the lights off.
Oh, we've seen the state change, now we get to move on.
This is still better done with wait groups,
and I'd ask us to be using wait groups here.
When we start talking about cancellation and deadlines,
I'm going to show you some examples of that.
We're going to be really using
this idea of a unbuffered channel,
where the data is the empty struct,
where we're really saying here that
what we're going to want to do is signal without data
and we want to be able to do that to many, many go routines.
If I had many, many go routines at one point,
all sitting on this same channel receive,
if I had all of these go routines blocked
on the same channel receive, at the same time,
then basically on the close, all of these,
all of these would then be able to unblock immediately
and keep running.
Okay, so this is our wait for finished.
So we've looked at our wait for task,
which is going to be really like pool related right?
The go routine gets lost,
it's now waiting for us to tell it what to do.
Then we also have, we had the wait for task,
then we're going to have to wait for result.
This is like a fan out pattern or drop pattern,
where we launch these go routines,
they know already what they have to do,
we're waiting for them to reply back with
whatever the result of their work is
and I'm going to have this wait for finished,
for cancellation and deadlines,
where we're going to use this to be able
to tell a go routine,
"hey, stop doing what you're doing,"
or be able to like indicate a wide scale,
that maybe we should be shutting down.