Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Figure out how to handle (un-)initialization of the Runtime #18

Closed
Boddlnagg opened this issue Aug 25, 2016 · 3 comments
Closed

Figure out how to handle (un-)initialization of the Runtime #18

Boddlnagg opened this issue Aug 25, 2016 · 3 comments

Comments

@Boddlnagg
Copy link
Collaborator

In other words, provide wrappers for RoInitialize and RoUninitialize and somehow ensure that the runtime is initialized before making other calls.

@Boddlnagg
Copy link
Collaborator Author

To statically prevent calling any WinRT functions without having initialized the runtime correctly (or after unintialization) is quite hard, if not impossible with current Rust. It would require adding a lifetime parameter to ComPtr which binds the lifetime to a runtime context returned by the initialization function. However, adding a lifetime to ComPtr is not easily possible, because it is used as associated type (RtType::Out), such that some impls would have a lifetime parameters and some don't. I don't know if this is possible without HKT.

@Boddlnagg
Copy link
Collaborator Author

In #25 we panic now with an appropriate message if RoGetActivationFactory is called without being correctly initialized. It is hard to get uninitialization wrong, but if one actually uninitializes while there are still WinRT objects alive, calling methods on them can lead to memory access violations, i.e. the thing that should not happen in safe Rust.

@Boddlnagg
Copy link
Collaborator Author

Closing in favor of #62, where the discussion has happened more recently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant