Static loader is unsafe

[emberian]

Scenario:

Thread 1              |  Thread 2
========              |  ========
driver1::make_current |
gl::load_with         |
                      |  driver2::make_current
                      |  gl::Begin() // crash!

In general, loading GL functions can be thread-specific, and only the struct loader can deal with this. Every function in the static loader should be marked unsafe, and it should be heavily discouraged.

[tomaka]

The struct loader is unsafe too, even if we mark it as NoSend.
You can make a context current, call Gl::load_with, then remove the current context, and all your calls will crash.

[ghost]

If you couple gl-rs with a library like glfw or glutin we can potentially build a completely safe api.

// this moves the window context to be part of gl
let gl = ctx.make_current();

gl.drawElements(...);
// ect

// this unwraps the gl moving the context back into ctx
let ctx = gl.to_context();

We could supply a trait to do this conversion for you, but it requires the windowing library to work with it.

[tomaka]

No, because if you create multiple windows you are still unsafe.

[ghost]

@tomaka the idea is that the opengl functions are queried each time you make_current.

[tomaka]

And how would you know that the user doesn't manually call wglMakeCurrent?
If he does, it's your code that ends up crashing. Hence the unsafe.

[brendanzab]

@csherratt Doesn't calling make_current over and over slow things down a great deal on Windows?

[brendanzab]

I am leaning towards making all functions in the static loader unsafe.

[emberian]

I think make_current should always be unsafe.

[brendanzab]

Agreed.

[brendanzab]

So the load_with function is safe, all gl functions are unsafe, and make_current is unsafe too?

[tomaka]

If we define unsafe as the safetiness of this function depends on factors not controllable by the function itself (in other words, the safetiness depends on the environment), then:

• all GL functions are unsafe because they are safe only if there is a valid context
• similarly get_proc_addr is unsafe because it requires a valid context
• make_current is safe, because the context passed to it is a Rust object and is always valid

Alternatively you could define unsafe as calling an unsafe function can lead to unexpected or unsafe behaviors in functions marked as safe (by an unsafe function, I mean make_current here), which is probably what csherratt had in mind.