go-gl/glfw3 — pull request #94 by slimsag (2014-09-02 01:54:56+00:00)
Title: Fix error handling deadlock.

@tapir and @shurcooL PTAL and let me know what you think.

This is an alternative fix for #92 (see most discussion in #86).

The original test program would output:

```
App started
Error 65540: Invalid window size
Error 65540: Invalid window size
GLFW: Uncaught error: 65539 -> Invalid argument for enum parameter
No deadlock
```

Which of course is incorrect (you should see two uncaught errors). Instead, we make it such that a call to Terminate flushes the pending errors so they are printed properly before the program exits.

The original test program (incorrectly) did not invoke Terminate, so a proper version is provided:

```
package main

import (
"runtime"
"fmt"
glfw "github.com/go-gl/glfw3"
)

func init() {
runtime.LockOSThread()
}

func main() {
glfw.Init()

fmt.Println("App started")

// Here is an error that is caught
_, err := glfw.CreateWindow(-5473548, 2354234, "Testing", nil, nil)
if err != nil {
fmt.Println(err)
}

// Here is another error that is caught
_, err = glfw.CreateWindow(-5473548, 2354234, "Testing", nil, nil)
if err != nil {
fmt.Println(err)
}

// Here is two uncaught errors
glfw.WindowHint(-23123, 0)
glfw.WindowHint(-23123, 0)

glfw.Terminate()

fmt.Println("No deadlock")
}
```

Which when ran has the correct output:

```
App started
Error 65540: Invalid window size
Error 65540: Invalid window size
GLFW: Uncaught error: 65539 -> Invalid argument for enum parameter
GLFW: Uncaught error: 65539 -> Invalid argument for enum parameter
No deadlock
```

It's OK that we require users to invoke Terminate to get correct output; as GLFW itself already requires this. If you don't invoke Terminate for instance the monitors gamma/resolution/etc may not be set back to correct values; *a program not invoking Terminate is an incorrect program period.*

This doesn't solve the fact that each GLFW function still needs to return an error for proper handling -- but this solves the immediate deadlock issue and doesn't suffer from the (implicit) data races in #92.