In the java world, it is called
Runnable. In the C# world, it is called
But, there is a better name which nicely fits within a larger view of things.
The larger view of things comes later, when you decide that besides your parameterless void functional interface you also need to have similar functional interfaces that accept one, two, or more arguments, or that return a value. When that happens, you will want the names of all those entities to be isomorphic and correspondent with each other.
So, in Java, I have my own set of functional interfaces that I call
Procedures, defined as follows:
public interface Procedure
public interface Procedure1<T1>
void invoke( T1 argument1 );
... (you get the picture.)
And I also have a similar set of interfaces called
Functions, defined in a similar way, with the first generic parameter being the return type:
public interface Function<R>
public interface Function1<R,T1>
R invoke( T1 argument1 );
So, my point here is that
Procedure is a very good name because it nicely fits within a larger view of things. If you later decide to have similar functional interfaces with methods that accept arguments or return a value, you will run into this.
NOTE: I basically do agree with Karl Bielefeldt's assertion that "normal naming principles should [not] go out the window" and that "Interfaces should almost always be named after what they do, not after some generic syntactic idea." But note that even he allows for "almost always". Sometimes there is a need for (essentially anonymous) procedures and functions, and that's what the OP is asking, and that's what I am answering.
You might ask, why
Function1<R,T1> instead of
Function1<T1,R>? It could go either way, but I have a preference for return values on the left because I like to follow the 'convert-from' (destination-from-source) naming convention as opposed to the 'convert-to' (source-to-destination) convention. (Which is more of an accident than a convention, really, in the sense that most probably, nobody ever gave it any thought, because if they had given it any thought at all they would have arrived at the 'convert-from' convention.)
I read about this in Joel Spolksy - Making Wrong Code Look Wrong, it is a very long article, which I recommend reading in its entirety, but if you want to jump straight to the case at hand, search for 'TypeFromType', but to give you the TL;DR, the idea is that
myint = intFromStr( mystr ) is much better than
myint = strToInt( mystr ), because in the first case the names of the types are close to the associated values, so you can easily see that the 'int' matches with the 'int' and the 'str' matches with the 'str'.
So, by extension, I tend to order things in the way they are going to appear in code.