`newLibraryWithData_error` but without requiring `dispatch2`

[jimblandy]

In gfx-rs/wgpu#8886 we ran into a situation where we had to introduce a dependency on dispatch2 solely because we wanted to use MTLDevice::newLibraryWithData_error, which takes a DispatchData argument. Since DispatchData is just a block of bytes, this seemed a bit silly; a more Rustic API would just take &[u8].

Would it make sense to offer an additional Rust function in MTLDevice that accepted the library data as a &[u8] and passed it through to the Objective C MTLDevice.newLibraryWithData:error: method somehow, without requiring the dispatch2 feature to be enabled, and without adding dispatch2 to the crate's dependencies?

[madsmtm]

DispatchData is not just a block of bytes: it may be several discontinuous blocks of bytes that logically represent a single block of bytes. There is value in preserving that as the interface, because it means that users have full flexibility and can more easily get the highest performing solution (e.g. instead of concatenating strings to create their library, they could choose to create two DispatchDatas and DispatchData::concat them instead).

That said, I understand the ask and annoyance, I myself am not a fan of unnecessary dependencies / dependencies where only a fraction is used. But I also want to keep the separation boundaries between my crates clean, it helps with maintaining things.

---

I think if wgpu wants to avoid the dependency, which I somewhat tend to think it should, one way to do it would be something like:

#[link(name = "System")] // libdispatch lives inside libSystem
extern "C" {
    fn dispatch_data_create(
        buffer: NonNull<c_void>,
        size: usize,
        queue: Option<NonNull<c_void>>, // dispatch_queue_t _Nullable
        destructor: *mut c_void, // dispatch_block_t _Nullable
    ) -> *mut AnyObject; // dispatch_data_t

    fn dispatch_release(object: *mut AnyObject); // dispatch_data_t
}

const DISPATCH_DATA_DESTRUCTOR_DEFAULT: *mut c_void = std::ptr::null();

pub(crate) fn new_library_with_slice(
    device: &ProtocolObject<dyn MTLDevice>,
    data: &[u8],
) -> Result<Retained<ProtocolObject<dyn MTLLibrary>>, Retained<NSError>> {
    let buffer = NonNull::new(data.as_ptr().cast_mut()).unwrap().cast();
    let data = unsafe {
        dispatch_data_create(buffer, data.len(), None, DISPATCH_DATA_DESTRUCTOR_DEFAULT)
    };
    assert!(!data.is_null());

    let res: Result<Retained<ProtocolObject<dyn MTLLibrary>>, Retained<NSError>> = unsafe {
        msg_send![device, newLibraryWithData: data, error: _]
    };

    unsafe { dispatch_release(data) };
    res
}

This would be what objc2-metal would have to do if I were to add a wrapper.

[madsmtm]

I'll leave this open, I'm still undecided whether I want to add such a wrapper to objc2-metal.

In any case, I would probably prefer for it to be a method on the trait itself (instead of an extension trait), but that needs changes in objc2, protocols like MTLDevice are implement-able in define_class!, and I don't currently have a good way to add optional non-Objective-C helper methods.

[madsmtm]

(Another problem in the general case for this sort of stuff is that linking a library is not a free operation, it forces the loader to do more work. Not actually a problem in this case, since the dispatch symbols live inside libSystem, and if not they'd likely be loaded by Metal.framework anyhow, but just something to keep in mind).

[inner-daemons]

@madsmtm I put basically your code into wgpu and it worked pretty much flawlessly. I'll put up a PR, this can probably be closed.