RAII type for HANDLES?

[damyanp]

Is there an RAII type for HANDLEs that'll call CloseHandle when dropped? As far as I can tell the current HANDLE requires an explicit call to CloseHandle.

[kennykerr]

No. The Win32 metadata, which defines HANDLE, doesn't have a reliable way to express ownership semantics. As you know, there are many uses of HANDLE, sometimes with different ways to free the handle, sometimes it is merely borrowed, sometimes representing a psuedo handle, etc. Ideally, the metadata would indicate such semantics on functions like CreateEventW to indicate what to do with the resulting handle.

[damyanp]

Ok, good to know I wasn't missing something. Has this already been discussed? Is this in scope for v1.0?

[kennykerr]

Ideally, the Win32 metadata can get improved support for ownership semantics. @riverar and I have discussed this at some length. He may have some thoughts as well. But I probably have to come up with some way to infer lifetime/ownership.

This is a general problem, particularly challenging with DirectX APIs where there are structs with COM interface pointer fields and it's not always clear who owns what.

[riverar]

Metadata has quite a bit of work ahead of it to make this work, or at least get it into a state where we can start experimentation.

For example, we're still tossing around candidates for how these attributes look microsoft/win32metadata#389. And we haven't nailed down a fix for free functions with multiple parameters microsoft/win32metadata#423. Or how to deal with functions that return either freeable and non-freeable resources based on other inputs microsoft/win32metadata#423 (comment).

[damyanp]

It seems that there are several different problems some of affecting legacy APIs while others are affecting more modern ones. Is the idea to fix all at once, or can these be prioritized at all?

The D3D APIs I think should be pretty trivial - the COM pointers in D3D12 structs are all weak references.

[kennykerr]

The D3D APIs I think should be pretty trivial - the COM pointers in D3D12 structs are all weak references.

By weak reference I assume you don't mean a weak reference? 😉 I was going to apply some sort of borrow semantics to indicate that they're not owned. That seems almost universal for Win32 structs (but not WinRT structs) so I may just make that work universally, but lifetime may be hard to figure out so I don't know how practical that is (#1896) so worst case they may have to just be ManuallyDrop.

For APIs that return resources, like CreatEventW for example, we really need the API to provide a FreeWith attribute on the actual function rather than the returned type. There already appears to be a FreeWith attribute that is used in some cases e.g. IBackgroundCopyJobHttpOptions.GetClientCertificate, but we'd need it to be rolled out more uniformly. Also, the issues @riverar mentioned. 😊

[Chaoses-Ib]

Here is a simple OwnedHandle:

use windows::Win32::Foundation::{HANDLE, CloseHandle};

/// You should only use this wrapper if the handle can be closed by `CloseHandle`.
#[derive(PartialEq, Eq, Debug)]
pub struct OwnedHandle(pub HANDLE);

impl From<HANDLE> for OwnedHandle {
    fn from(handle: HANDLE) -> Self {
        Self(handle)
    }
}

impl Drop for OwnedHandle {
    fn drop(&mut self) {
        unsafe { CloseHandle(self.0) };
    }
}

[MarijnS95]

@Chaoses-Ib (and @NiiightmareXD, #2638) there is already a stabilized Rust type that encapsulates HANDLE and calls CloseHandle() on drop(): https://doc.rust-lang.org/stable/std/os/windows/io/struct.OwnedHandle.html

While it currently seems to be impossible for windows-rs to know when ownership transfer occurs (see above: the metadata doesn't describe this), perhaps it could at least implement some of these std traits such as AsHandle and AsRawHandle, and maybe an fn into_owned_handle(self) -> OwnedHandle?

[riverar]

Don't think we have any plans to adopt those std traits/structs. Opinion: At a glance, the handle work there looks very brittle and naive.

[MarijnS95]

@riverar perhaps it is worth to voice your concerns (if you haven't already done so) upstream?

[kennykerr]

See #3013 for a solution.