Exact glFinish and glFlush semantics

I am in the process of writing a pure software programmable rasterizer and I am trying to keep the interface as close as possible to OpenGL. I am keeping very close to OpenGL so that new user won’t be alienated by an unfamiliar interface and also I can always write a wrapper that includes full OpenGL functionality instead of rasterization-only. Now I’ve got a problem understanding the exact semantics of glFinish and glFlush. In my curren implementation when glFinish is called I just execute all the commands I have received and return control to the user. But that’s also exactly what I do with glFlush()… The OpenGL 1.5 spec provides little information about the difference between the two functions. I am coming up with a slightly different version of flush but which requires a lot of tweaking to my current implementation. This version sets up another set of empty buffer for receiving more operations and spawns another thread which starts executing the operations contained in the previous buffer returning immediately control to the calling thread. Now this looks like an async version of glFinish so I am unsure on whethever it is correct or not. Any suggestions about this? I’d like to be as coherent as possible to current OpenGL implementations to avoid surprises when I’ll start porting OpenGL code to my rasterizer.

The second implementation seems perfectly correct to me.
But if your first implementation of glFlush guaranties to “complete in finite time” all previously issued gl commands, you can keep it. As “glFlush can return at any time”, it can return after processing all commands.
If you are doing single CPU software rendering, I believe that there is no need to complexify your first implementation.

The difference between the glFlush and glFinish is mostly to improve parallelism with the former. Or am I wrong ?

I completely agree with ZbuffeR.
glFlush and glFinish are distinct because it is expected that an OpenGL implementation backend in itself is in some ways asynchronous. This is the case for most hardware accelerated implementations because a graphics chip can do stuff at the same time as the (single) host processor.

Or take the GLX wire protocol, where the GL server may be on a completely different machine and is connected through a network.

A multithreaded approach would nicely simulate this behaviour, but it isn’t required for compliance.

I see, probably I’ll stick with the first version were glFlush and glFinish have the same behaviour. Sticking another thread inside is a little bit awkward and also you run the risk of spawning a lot of threads for repeated calls to glFlush which would slow down the system. Basically I prefer to keep it a single-thread rasterizer though it is not hard to parallelize. I prefer to draw two frames at a time (one per processor) with two separate contexts to take advantage of a second processor. This way the implementation suffers only minimal overhead due to syncronization.