-
-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mutable and sendable #41
base: main
Are you sure you want to change the base?
Conversation
let _default: Datum = Lists[I32]([0; 0; 0; 0]) | ||
|
||
new create() => | ||
_data = mut.Map[USize, Datum](268_435_456) // == 2 ** 28; point being a non-trivially sized data structure, use your imagination |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you move the comments above the line so it works better on smaller screens?
same below as well
Can you work in references to the other patterns that this builds on that are mentioned elsewhere in this section? I think showing how this builds on them would be very helpful for someone understanding what is going on with the pattern. |
…ences to other Data Sharing patterns in Discussion.
|
||
## Problem | ||
|
||
Suppose you have a central Supervisor actor that manages a very large data structure that contains the work produced by a collection of Worker actors. However, the Superviser must also respond to data requests (perhaps from the Workers themselves, or in this case, from another set of Requester actors). As a result, the Superviser's data structure must be both mutable (to update it in response to feedback from Workers) and sendable (to respond to requests from Requesters). `iso` is the only refcap that accommodates that, but our Supervisor can't use `iso` here because it must keep a reference to the data structure to continue to respond to incoming updates and requests. How to proceed? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
" iso
is the only refcap that accommodates that"
what "that" refers to is unclear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you have a really good introduction to the problem here, but you should let it breathe. This is a rather complicated scenario and I think you should look to expand the explanation of the problem quite a lot. Like 3-4x more content to dig in more seems completely reasonable (if not more).
I don't think I would understand the problem were it not for working through a solution with you in Zulip.
|
||
type Datum is List[I32] | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can drop the extra newline here.
_supervisor = supervisor | ||
|
||
be do_work(id: USize) => | ||
let result = [as I32: 1; 2; 3; 4] // initial state array |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
on small screens, this side comment is hard to deal with, can you move it above the let result
. The same comment would apply elsewhere.
``` | ||
|
||
|
||
The Supervisor uses a mutable `ref` Map collection of persistent immutable `val` Lists. Because the Map is mutable, new data can be easily added or updated without the copying costs required by a persistent Map. Because we're storing the individual work product (Datum) in persistent immutable Lists, they are refcap `val` which accommodates sharing with Requesters. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels rather tacked on after the solution. This suggest to me that it should be part of a discussion or it needs to be expanded. I'm leaning towards, only code in solution and then do a breakdown of the different bits of code and what they are doing in the discussion.
I'm imagining something like how the solution is broken down in the waiting pattern. https://patterns.ponylang.io/async/waiting.html
I think that breakdown should be part of the solution which leaves you free to cover in Discussion how it relates to the other patterns you reference there.
@erdman I left some comments. I think you have the basis of a very good pattern here. Keep going! |
Hardest part of this was naming the pattern. Feel free to revise that or any part of the text. Appreciate Sean's help in getting to this solution for my project ... hopefully this writeup is something you can work with for the Patterns book.