Network Vtable

[lightsighter]

Proposed interface for a network vtable.

One open question is to define the thread-safety of the callbacks. Will Realm provide the thread safety or will the client need to do that?

Another open question: do we think we'll ever need variable-sized key value data? Currently the interface assumes we'll always know the resulting value size in advance before doing a get call.

[codecov]

Codecov Report

❌ Patch coverage is 82.00000% with 63 lines in your changes missing coverage. Please review.
✅ Project coverage is 28.22%. Comparing base (3099b1d) to head (07e2d7d).
⚠️ Report is 2 commits behind head on main.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
src/realm/runtime_impl.cc	43.90%	41 Missing and 5 partials ⚠️
tests/unit_tests/key_value_store_test.cc	94.36%	15 Missing ⚠️
src/realm/realm_c.cc	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #366      +/-   ##
==========================================
+ Coverage   27.74%   28.22%   +0.47%     
==========================================
  Files         192      193       +1     
  Lines       39502    39849     +347     
  Branches    14194    14436     +242     
==========================================
+ Hits        10960    11247     +287     
- Misses      27112    28206    +1094     
+ Partials     1430      396    -1034     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sbahirnv]

I like the interface!

I will try to come up with mini-app which would use this interface to bootstrap Realm.

[lightsighter]

Another thing that I'm waffling on a bit is whether to pull the optional methods for join and leave into a separate interface that can be registered dynamically while execution is taking place and will support multiple "subscribers" for notifications of other processes joining and leaving. I think this is probably we're going to want so that different Realm clients can all subscribe without having to coordinate with each other. The bootstrap callbacks don't have this requirement obviously since there's only one client that is ultimately ever going to start Realm in a process.

[sbahirnv]

Another thing that I'm waffling on a bit is whether to pull the optional methods for join and leave into a separate interface that can be registered dynamically while execution is taking place and will support multiple "subscribers" for notifications of other processes joining and leaving. I think this is probably we're going to want so that different Realm clients can all subscribe without having to coordinate with each other. The bootstrap callbacks don't have this requirement obviously since there's only one client that is ultimately ever going to start Realm in a process.

If I understand correctly: one process links against librealm.so, but different parts of that process can register for join/leave notifications. Only one part actually calls init()/start() though. If so, I like the idea of separating join/leave into its own interface because different parts need different things. Like, a monitoring system might only care about tracking who joined and left, while the main app is using Realm to actually do work. Both can do their thing independently. It makes the registration a bit messier since multiple parts are registering, but with added benfits.

[lightsighter]

Another thing that I'm waffling on a bit is whether to pull the optional methods for join and leave into a separate interface that can be registered dynamically while execution is taking place and will support multiple "subscribers" for notifications of other processes joining and leaving. I think this is probably we're going to want so that different Realm clients can all subscribe without having to coordinate with each other. The bootstrap callbacks don't have this requirement obviously since there's only one client that is ultimately ever going to start Realm in a process.

If I understand correctly: one process links against librealm.so, but different parts of that process can register for join/leave notifications. Only one part actually calls init()/start() though. If so, I like the idea of separating join/leave into its own interface because different parts need different things. Like, a monitoring system might only care about tracking who joined and left, while the main app is using Realm to actually do work. Both can do their thing independently. It makes the registration a bit messier since multiple parts are registering, but with added benfits.

Yes, many things can be using Realm, although there is just one that needs to be responsible for starting Realm. Multiple clients of the same Realm (e.g. both Flash Cache and Dynamo) might want to subscribe to notifications about processes joining and leaving the Realm independently.

[sbahirnv]

Interface looks great to me!

Before merging though, we need the network_init() implementation or it won't link. Want me to implement it based on your interface design(I can fork from this branch and continue), or are you planning to do that?

I'm going to test it to bootstrap UCX backend.

[lightsighter]

One other note on this is that I removed the join/leave callbacks. I don't actually think they are necessary once you look at the machine subscription interface. The machine subscription interface does need a bit of work, but I think we can handle that separately from this API.

[apryakhin]

Another thing that I'm waffling on a bit is whether to pull the optional methods for join and leave into a separate interface that can be registered dynamically while execution is taking place and will support multiple "subscribers" for notifications of other processes joining and leaving. I think this is probably we're going to want so that different Realm clients can all subscribe without having to coordinate with each other. The bootstrap callbacks don't have this requirement obviously since there's only one client that is ultimately ever going to start Realm in a process.

First of all we probably don't need separate join and leave but just a single callback with an action type. Second is that with the "watch(prefix, callback)" interface you accomplish exactly that. The registration is dynamic...anywhere inside realm at any time you should be able to subscribe to notifications. The semantics of watch and to implement efficiently is not easy though.

However, I might have misunderstood the reasoning behind the need to remove that at all or rather move to another interface.

I think there are number of different ways to do the vtable in general and since you started thinking about it I see that it diverges somewhat from my original thinking (and that's okay). I still cannot understand by how much. Although, we maybe need to sync and discuss again the semantics of it to make sure we are on the same page here.

[apryakhin]

One other note on this is that I removed the join/leave callbacks. I don't actually think they are necessary once you look at the machine subscription interface. The machine subscription interface does need a bit of work, but I think we can handle that separately from this API.

What would be helpfull is a little pseudo-code snippet that would show-case how this vtable is going to be used. Perhaps that's not on you but since you are taking a stab at this interface anyways .

[lightsighter]

However, I might have misunderstood the reasoning behind the need to remove that at all or rather move to another interface.

The reasoning is that we actually already have an interface for this in the Machine class. It looks like it is not fully implemented, and it definitely needs some work, but I think I prefer that than making it part of the bootstrapping interface.

What would be helpfull is a little pseudo-code snippet that would show-case how this vtable is going to be used.

We can discuss this in the meeting tomorrow, but I may be willing to do the first-pass implementation of the UCX bootstrap using this interface.

[apryakhin]

PMIX:

• Add PMIX #349