Flush command streams after deleting resources

Flush command streams after deleting resources

When share groups and pooled IDs are in use, a race condition exists when destroying resources since
the IDs are marked as free before the resource is actually freed.  Consider:

Context A creates a framebuffer with id 1
Context B is created in the same sharegroup as A
Context A destroys its framebuffer:
- the ID is freed (via FreeIDs(), which is a synchronous call)
- a DeleteFrameBuffersImmediate command is entered into A's command buffer but does not immediately execute
Context B creates a framebuffer
- genFramebuffer() makes a sync call to the service side, which reports that id 1 is available

At this point, if the service side processes and commands in context B's command stream, it will throw kInvalidArguments
because as far as the service side is concerned framebuffer 1 has never been released.

This patch adds a Flush() after destroying a resource so that the service side will process the resource destruction
command before servicing other command streams.  There's still a potential race condition if multiple contexts in the
same share groups are making calls from different threads, but today all contexts in the same share group are on the same thread.

BUG=80703
TEST=none


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=95576

[jamesr, 2011-08-04 22:48:45]

http://codereview.chromium.org/7574024/diff/1/gpu/command_buffer/common/gles2...
File gpu/command_buffer/common/gles2_cmd_utils_implementation_autogen.h (left):

http://codereview.chromium.org/7574024/diff/1/gpu/command_buffer/common/gles2...
gpu/command_buffer/common/gles2_cmd_utils_implementation_autogen.h:409: {
0x889F, "GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING", },
note: these changes showed up when i ran the script, guessing it was just stale

[apatrick_chromium, 2011-08-04 23:50:05]

LGTM

[commit-bot: I haz the power, 2011-08-05 04:21:53]

Change committed as 95576