Allow [Threadsafe] interfaces access to Arc<Self>

[mhammond]

We've a use-case where it would be ideal to have access to a clone of the Arc<Self> stored in the ArcHandleMap.

The motivation here is for an app-services component to register with the "sync manager". Without going into too much detail about the "spelling", think something like:

[Threadsafe]
interface Foo {
  [SomethingSomething]
  void register_with_something_external();
}

makes sense, where we call something with the signature:

fn register_with_something_external(self: Arc<Self>) { ... }

which leverages "method receivers". The intent is that we can avoid something gross like an <Arc<Arc<T>> and instead leverage the fact that uniffi already manages the Arc we need.

I'm opening this as a place-holder issue, trying to avoid too much bikeshedding at this stage (hence [SomethingSomething] :) - but I welcome it in general.

cc @rfk @lougeniaC64 @jhugman @dmose

┆Issue is synchronized with this Jira Task

[rfk]

The intent is that we can avoid something gross like an <Arc<Arc> and instead leverage the fact
that uniffi already manages the Arc we need.

I haven't thought about this very deeply, but high-level, I'm concerned about leaking an incidental implementation of uniffi in this way. We happen to currently use an Arc<T> and a handlemap for [Threadsafe] interfaces, but we might want to try changing to something like a Box<T> in future for performance reasons.

Again without thinking very deeply, I wonder if it would be possible to invert the responsibility here, and have a way for you to declare that your interface is already inside an Arc<T> and you don't need uniffi to add a second one on for you. That would solve the double-arc problem, but I guess it wouldn't solve the "have to manually wrap your object in an Arc rather than having uniffi do it for you" problem...

[mhammond]

I'm concerned about leaking an incidental implementation of uniffi in this way.

Yes, good point. Off the top of my head, maybe unifying (ha!) what constructors return and what I'm trying to achieve here - ie, defining what Self is? That might be somewhat orthogonal to ThreadSafe but might scale better...

[rfk]

I'm concerned about leaking an incidental implementation of uniffi in this way.

I should also say, I'm not prepared to rule out such leakage entirely - for example in the hand-written bindings for places etc I believe we have some sort of getHandle() method that deliberately leaks the implementation detail of "we are using a handlemap". I just want to make sure we consider the tradeoffs involved.

unifying (ha!)

I will be really pleased if we come up with another name for a thing that keeps showing up in conversations in the same way that "sync up (ha!)" has been doing for our team for years 😆

[rfk]

We happen to currently use an Arc and a handlemap for [Threadsafe] interfaces,
but we might want to try changing to something like a Box in future for performance reasons.

It occurs to me in the light of day, that Arc<T> is basically a Box<T> with some extra refcounting stuff in the allocation, and in fact all the fun converting to/from a raw pointer that you can do with a Box<T> you can also do with Arc<T>. You can even easily check whether two Arc<T>s point to the same data, which would help the Prestige-style bidirectional mapping problem that @jhugman has mentioned in other issues.

So...maybe I wouldn't actually be too upset if we "leaned in" to the use of Arc<T> at the interface layer here in general.

[mhammond]

So...maybe I wouldn't actually be too upset if we "leaned in" to the use of Arc<T> at the interface layer here in general.

Another option might be to allow the UDL to somehow say "I want an Arc<>" - so lean in to always supporting the use of an Arc, but don't quite commit to "interfaces marked as [Threadsafe] will forever use Arcs".

[mhammond]

(OTOH though, I think being opinionated here is fine - there's no need for us to support theoretical future use-cases that will probably never exist)

[jhugman]

For clarity, I'm not sure I understand the problem space enough to make an informed comment. I think this might be worth probing more deeply in a synchronous setting.

[rfk]

So...maybe I wouldn't actually be too upset if we "leaned in" to the use of Arc at the interface layer here in general.

Cross-linking for reference, it turns out that when I said "wouldn't be too upset" what I actually meant was "am about to go on a deep dive about making Arc<T> a fundamental part of the contract between UniFFI and the Rust code": #419.

@mhammond, I think what I'd proposing there is a generalization of what you're talking about here, and if we like the general direction we could consider some sort of [Self=ByArc] annotation on the method receiver as a first step in that direction.

I think this might be worth probing more deeply in a synchronous setting.

Also, +💯 to talking it through in a synchronous setting if we feel like there's something here we want to move on.

[rfk]

I believe we have broad agreement that what's being requested here is a subset of what we'll implement as a result of #419, so I'm going to close this issue out.