[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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?

Attachment: signature.asc
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]