Skip to content
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

Would you please explain me that is the goal of this case? #6

Open
ashirko opened this issue Feb 21, 2019 · 2 comments
Open

Would you please explain me that is the goal of this case? #6

ashirko opened this issue Feb 21, 2019 · 2 comments

Comments

@ashirko
Copy link
Collaborator

ashirko commented Feb 21, 2019

https://github.com/mrallen1/gisla/blob/4daf8e11fed6eba95a362cfccd391c8b5165866f/src/gisla.erl#L213

@jadeallenx
Copy link
Owner

It is possible that we can receive an exit message before an error message, so this just ensures that there are no other messages in our mailbox before we exit.

@ashirko
Copy link
Collaborator Author

ashirko commented Mar 5, 2019

Message 'race_conditions_are_bad_mmmkay' can be received only after receiving {complete, NewState}. Receiving {complete, NewState} means that operation_fun is completed successfuly. Moreother, demonitor(Mref, [flush]) deletes exit message if it is in a mailbox. Thus, receiving 'race_conditions_are_bad_mmmkay' is the only option after receiving {complete, NewState}.
So, maybe after receiving {complete, NewState} we should return {ok, normal, State} instead of recurcive calling 'loop', and remove 'race_conditions_are_bad_mmmkay' case?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants