Distributed module documentation #326
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Konrad originally drafted this content in RST, in May 2022. Alex converted it to markdown without preserving the Git history, because that history was only one commit that added this content. The original parent commit was ed422ae.
martialln
reviewed
Aug 7, 2024
| we registered a closure to be called at some later point in time when some additional information was looked up by the | ||
| actor. In local-only actors, a common way of modeling this is passing a closure to the actor. | ||
|
|
||
| In distributed actors, the same can be achieved using distributed method calls rather than closures, like this: |
There was a problem hiding this comment.
We should explain that Alice and Bob must share the same ActorSystem. Also there are two cases: is Bob type known on Alice side or not
| print("later: \(laterReply)") | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
Using resolvable protocol we could have something like that:
@Resolvable
protocol InfoListener: DistributedActor, Codable {
distributed func additionalInfo(_ info: String)
}
distributed actor Alice {
distributed func call(later: $InfoListener) async -> String {
Task.detached {
// do some asynchronous processing AFTER returning from the 'call' method...
try await later.additionalInfo("Here's the info you asked for!")
}
return "Thanks for your call!"
}
}
distributed actor Bob: DefaultDistributedActorSystem.SerializationRequirement {
func test(alice: Alice) async throws {
let infoListener = try $InfoListener.resolve(id: self.id, using: self.actorSystem)
let immediateReply = try await alice.call(later: infoListener)
print("immediately: \(immediateReply)")
}
}
extension Bob: InfoListener {
distributed func additionalInfo(_ info: String) {
print("later: \(info)")
}
}There was a problem hiding this comment.
That one's tricky, I would not want $ types in distributed method signatures but perhaps there's no workaround yet... I'll dig into this one
akbashev
reviewed
Aug 8, 2024
There was a problem hiding this comment.
Overall like the page, gives a quick recap of the module!
Want to reread it a bit later with a fresh mind, but at the moment have two small comments. Added them as suggestions, but take them with a grain of salt.
- Overall I think would be nice to add some small sentence on why exactly one should use
distributedmodule. - Think memory management could also be highlighted—it's not quite obvious at a first glance. Though not sure about placing, it's quite specific. Maybe even be placed in
Implementing Your Own DistributedActorSystemsection as it's mostly for systems to care about?
| The actor system may return a local or remote reference, however it should not perform asynchronous work such as | ||
| trying to confirm if the actor exists remotely or not. The resolve method should quickly return either a known | ||
| local actor identified by the passed `id` or a remote reference if the actor may exist remotely. | ||
|
|
There was a problem hiding this comment.
Suggested change
| > Note: Be careful with memory management. Local actors already stored on the node, so it might be better to keep references to them as weak. However, for remote actors reference is generated, which could potentially be cleaned if not kept strongly. // TODO: Link to Automatic Reference Counting page? | |
There was a problem hiding this comment.
Hmmm, I agree we need to document this but maybe needs its own section with more info.
Thank you for the input everyone! I'll keep working on this :) Co-authored-by: Jaleel Akbashev <[email protected]> Co-authored-by: Martial Lienert <[email protected]>
ktoso
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a very early version of
Distributedmodule documentation; It is not polished up, may have stray sentences and sections etc.We'll figure out how to best present the information through the pitch posted on the forums over here:
I'll also work on improving tone and voice still, right now it is not the most consistent.
For now, we can discuss what needs to be explained in this documentation and I started a forums thread for this purpose: TSPL Pitch: Distributed.