D5438: rust-cpython: implementing Graph using C parents function

[yuja (Yuya Nishihara)]

yuja added a comment.


  > +/// # TODO find a solution to make it GIL safe again.
  >  +///
  >  +/// This is non trivial, and can wait until we have a clearer picture with
  >  +/// more Rust Mercurial constructs.
  >  +///
  >  +/// One possibility would be to a `GILProtectedIndex` wrapper enclosing
  >  +/// a `Python<'p>` marker and have it be the one implementing the
  >  +/// `Graph` trait, but this would mean the `Graph` implementor would become
  >  +/// likely to change between subsequent method invocations of the `hg-core`
  >  +/// objects (a serious change of the `hg-core` API):
  >  +/// either exposing ways to mutate the `Graph`, or making it a non persistent
  >  +/// parameter in the relevant methods that need one.
  
  Thinking this a bit further, I'm getting to feel that a "non persistent
  parameter" will be an easier choice.
  
  If an `Index` object were implemented in pure Rust, it would hold the entire
  index data in memory. As we wouldn't want to memcpy such large object, there
  would be some reference types (e.g. `&Index`, `Rc<Index>`, etc.) involved
  somewhere. For instance, `AncestorsIterator<G>` might have to be
  `AncestorsIterator<G: 'g>`, and holding a reference would slightly complicate
  things in a similar way to holding `Python<'p>`.
  
  `Index` could be backed by e.g. `Rc<RefCell<_>>` to allow any objects to own
  `<G: Index>` copies, but I don't feel like this is a good design.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D5438

To: gracinet, #hg-reviewers
Cc: yuja, durin42, kevincox, mercurial-devel