-
Notifications
You must be signed in to change notification settings - Fork 35
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
Advice for adding an heir #11
Comments
Adding comments from README to discussion:
Should we behave like ports or more like an ETS table? I think the ETS heir/give_away seems more appropriate since I want this for cases where my process fails. |
A map argument for the header would be neat; we could conditionally export it based on maps availability in the language as long as use As for the message format, I would look at what ETS does. For the Do note the following in the docs:
I think we wouldn't have to enforce the locality of the pid (since we do it by hand and it's not a BIF/NIF limitation, but we should respect the liveliness and the owner. It would also make sense that if we allow both a give_away and a heir, we respect the same policies as ETS. |
Did you know that See here Well I guess I will do some really ugly stuff with |
ah yeah all OTP processes capture it directly. They can still call Otherwise setting a heir might work better if the POBox unlinks itself from its parent and replaces it with a monitor, which would then allow to handle things right (no auto-triggered EXIT, but the POBox user won't die if the POBox dies, which isn't ideal). We'd also need to link ourself to the new heir once the parent has triggered a 'DOWN' message. |
I have something like this that seems to work:
I can do a monitor instead if you really think this is too hacky. The benefit of course is that if we crash the link will function as expected. |
See #13 for the current status of implementation. |
Heir functionality:
Give away functionality:
|
Today I will be looking for ways around map syntax and seeing what modifications would be required for monitor instead of link without changing the behaviour of pobox. Possibility we need to be more careful about running external code in pobox since we are essentially an error kernel the second we switch to monitor. |
Sounds good. I'll try to set time aside to review the PR. |
@ferd I just pushed my changes for today. It's not completely done yet but I would say it is most of the way there. |
The main issue to resolve is do we transfer ownership when the owner terminates normally? |
A heir would generally mean that no matter which reason killed the owner, it gets transferred anyway. Any exit signal from the owner should count the same. |
I guess we have it set up that way already. How can we be convincing about having covered all of the cases? Do you have suggestions on property based tests we could run on this? I am still new the property based testing. We could compare bahviour with ETS. |
Properties are not necessarily critical here. The thing that I think would make sense to test the most is ensuring that transferring the ownership always resets to a passive mode. A good property test would probably be one that is stateful or a state-machine property. We should have it simulate all the operations we want:
through each of these we have to define invariants we want to maintain in the model's state: who has seen what messages, what are they, what are the states we can check? The property is going to run the list of 7 commands above in a random order and we will have to be able to predict the outcome of each operation. The weakness of that property would be in the case of an active pobox where we send a message and instantly die; it is possible that pobox will forward the message to a process that already died before noticing about it (especially if it is severely backlogged) and so this will ruin model predictability. As such, it might make sense to only test the notify and passive modes with such a property. Do note that this property would ignore everything related to message drops and metrics; it is purely about validating behaviour around transfers. Dropping and metrics could be tested in a distinct property. If you feel like trying your hand at that, let me know whatever kind of help you might need, but I wouldn't block the PR on having this feature around unless you wouldn't feel safe about it without the tests. |
Thanks for the input. I will work on it. I am going to be deploying this into production in the not too distant future which is why I need to test this as much as possible. By the way, check out the travis build it looks like we don't support anything older than Erlang 19 because of gen_statem. I might remove prop list support; also I might remove checks for map support. |
I have addressed the remaining issues. Feel free to merge the PR when you are ready. |
Hi,
I want to add an heir to my
:pobox
so that another process in case of failure can inherit it. I need some advice about how to implement various aspects of this. I would also like to get your thoughts or suggestions before I start implementing it.The first issue I see is that the start_link argument list is getting long. For example, could I provide a start_link(Opts) and start_link(Name, Opts) that would have a map of options. Do we need to support versions of Erlang older than 17 and is that a good way of dealing with this?
What about the format of the message sent when the heir is to take over, what fields would be included?
Any advice, suggestions, concerns would be much appreciated.
The text was updated successfully, but these errors were encountered: