Surface::set_mime_data() shouldn't require a static lifetime on the data about cairo

[sdroege]

I think it's enough to pass a regular reference?

No as the data has to live until the destroy function is called. It can outlive the current stack frame

[federicomenaquintero]

I mean, doesn't Box::new(slice) copy the slice into the heap?

Going back... if we wanted this function to avoid a copy, wouldn't it have to take ownership of a Vec or whatever? What's the idiomatic way of transferring ownership of a byte buffer?

[sdroege]

@federicomenaquintero Vec<u8> is implementing AsRef<[u8]> and you can pass it into that function directly. No copying will happen then, same thing with basically everything else that has the memory heap allocated.

If you put an array in there, it will be copied from the stack to the heap indeed.

[federicomenaquintero]

I think what happens is this:

pub fn set_mime_data<T: AsRef<[u8]> + 'static>(&self, mime_type: &str, slice: T) -> Result<(), Status> {
        let b = Box::new(slice);

The Box::new(slice) creates a heap allocation big enough for the slice (ptr, usize) and moves the slice there. Below, there is this:

        let user_data = Box::into_raw(b);

        let status = unsafe {
            let mime_type = CString::new(mime_type).unwrap();
            ffi::cairo_surface_set_mime_data(self.to_raw_none(),
                mime_type.as_ptr(),
                data,
                size as c_ulong,
                Some(unbox::<T>),
                user_data as *mut _,
            )
        };

The destroy func is unbox, which will free the tiny allocation for (ptr, usize)... but the original buffer has a static lifetime.

I think the semantics of cairo_surface_set_mime_data is to take ownership of the buffer passed to it, and the C-ism there is to provide the destroy func. If this is correct, I think this wrapper should instead take ownership of a buf: Vec<u8>. This avoids copies; the wrapper can then manage that Vec as it wants. (Maybe just box it and pass the into_raw to the Cairo function?).

Alternatively, we can keep it taking a slice (or an AsRef<[u8]> like right now) but really do a copy internally. I think the static lifetime requirement makes the wrapper as it is rather useless. For example, librsvg will read JPG referenced from the SVG, and then surface_set_mime_data with that JPG buffer. But it can't be done with a static lifetime.

[federicomenaquintero]

Cooking a patch right now.

[sdroege]

You apparently didn't see my comments on IRC :)

federico: for your cairo issue, your analysis about passing arrays is correct. you don't really want to do that
federico: but if you look around what else implements AsRef<[u8]> you'll see that e.g. Vec<u8> also implements that. or a gst::MappedBuffer. or a hyper::Chunk. or ... :)
federico: you can pass any of these in there and e.g. in the case of a Vec the only thing copied to the Box is the metadata of the Vec (pointer, capacity, length)
federico: the 'static on the data only means that it must have no references itself to any non-static things. i.e. you can't pass anything in there that has references to a stack frame for example. fully heap allocated data is fine, for example. and the function takes ownership of the thing you pass there
federico: oh, Arc<Vec<u8>> also implements AsRef<[u8]> btw if you want to prevent some copies ;)

[sdroege]

E.g., try surface.set_mime_data("foo/bar", vec![1, 2, 3, 4u8])

[sdroege]

We use the same pattern for gio::OutputStream::write_async() etc btw, and also in GStreamer for wrapping arbitrary things that are like byte arrays in buffers. So that's a well-established pattern that works fine elsewhere.

[federicomenaquintero]

OMG, then I think my problem may have been that I was passing &myvec instead of transferring ownership of myvec. I'll try that again in librsvg. Thanks!

[sdroege]

Ok, let's close this then?

[sdroege]

@GuillaumeGomez can you close this for now? :)

[GuillaumeGomez]

Sure.