[Libguestfs] [PATCH] Rust bindings: Implement Event features

[Martin Kletzander]

On Tue, Jul 30, 2019 at 09:43:26PM +0900, Hiroyuki Katsura wrote:
>> So this has a lifetime same as the whole handle?
>
>Yes.
>
>> Why do you then need to keep
>> it in the list of callbacks then?
>
>Because I want to make sure that callbacks must exist while they are
>running.
>

But both of the things are trying to accomplish the same thing, my question was
why are you using _both_ approaches to keep the pointer valid?

>> Also you explicitly leak it here, so even
>> without a lifetime it will not get freed.
>
>If you do not explicly write lifetime here, the pointer will have static
>lifetime.
>
>https://doc.rust-lang.org/std/boxed/struct.Box.html#method.leak
>

Oh, it *has* to have one, the only one that you can choose here is 'static.

>I think It is too long. But I think there is no more 'correct' lifetime
>than 'a.
>

For callbacks that can get called multiple times, yes.  Or until you delete it
at which point you can clean it.

>Actually, I wanted to use Weak::into_raw there. However, it is
>nightly-feature now.
>
>>  if you do Box::into_raw instead of Box::leak, you get a *mut right away
>> that you do not need to cast twice, I believe.  Otherwise it should be
>the same,
>> I think.
>
>If you use Box::into_raw, you must make sure that they are freed by
>yourself.
>However, if the box pointer is passed to the guestfs API, the pointer will
>continue to live
>without being freed after the guestfs handle which contains the passed
>pointer has closed, I think.
>On the other hand, by using Box::leak, you can assure that they live until
>the handle closes.
>But the buffer will be freed when the guestfs is dropped. So, passing this
>pointer
>will not cause memory leak.
>

So I'm misunderstanding the documentation probably.  From Box::leak:

  "This function is mainly useful for data that lives for the remainder of the
   program's life. Dropping the returned reference will cause a memory leak. If
   this is not acceptable, the reference should first be wrapped with the
   Box::from_raw function producing a Box. This Box can then be dropped which
   will properly destroy T and release the allocated memory."

Just for completion sake, Box::into_raw:

  "After calling this function, the caller is responsible for the memory
   previously managed by the Box. In particular, the caller should properly
   destroy T and release the memory. The proper way to do so is to convert the
   raw pointer back into a Box with the Box::from_raw function."

Which, I feel, is a different wording of the same situation.  Especially since
both of them can then be used with Box::from_raw().  The only difference being
that one returns pointer and the other one a reference (which can have a
lifetime associated with it).


Actually, thanks to the awesome way the docs work, I can just click the `[src]`
link and find out that:

    pub fn leak<'a>(b: Box<T>) -> &'a mut T
    where
        T: 'a // Technically not needed, but kept to be explicit.
    {
        unsafe { &mut *Box::into_raw(b) }
    }

Anyway, I must admit that even though I am talking about this like it was
written badly, I actually do not know about a better way if the handle can be
dropped while the callback is executing.  So maybe the question is, can this
really happen?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20190731/bc57bf91/attachment.sig>