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.
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
Add support for async requests #228
Add support for async requests #228
Changes from 27 commits
9daf971
8adbf5d
8aee995
785616c
bb3beaa
186385e
fc97489
5cbba4e
4f7e31e
00e1752
f29b841
69d37d6
0b65bc8
e43a005
6632115
8968a2e
4d63e0b
a1f81d2
7af3595
42d3fbe
6e75444
3142972
cf3e822
c12aeec
efdb914
1289f7d
d4f86b5
8bae1ce
9ae43ef
f89106b
83b538a
f53e8e4
4d259b6
aa2ced7
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Maybe we should link?
This will make sure any unexpected crashes will propagate up.
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.
If we link, there may be no need to monitor, as this process we crash. Alternatively we link, trap exits, and monitor.
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.
Yep, that would definitely simplify things. I was thinking that we wouldn’t want internal crashes to take down the caller, only the caller to take down the request, but the request crashing already means the caller isn’t going to receive messages it’s probably expecting, so it’s probably better to just crash.
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.
@josevalim See 9ae43ef -- do you have any insight into why the
spawn_link
process doesn't immediately terminate when the caller does? Specifically, this test was failing when I stripped out the monitoring code. I also tried addingProcess.flag(:trap_exit, true)
inside the anon fn and then changingprocess_down?(monitor)
to ashould_exit?()
that looks for an{:EXIT, _, _}
message, but didn't seem to receive one.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.
In this code:
the spawned process immediately exits with reason
:normal
aftersend/2
, which does not lead to any broken link. So by the time you send it a exit signal, it is already gone. Adding aProcess.sleep(:infinity)
should fix it.It it up to you to decide if we still need monitoring. If you start something to stream asynchronously and you never consume it, what does it mean?
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.
Oh, duh! Thank you.
I’ll fix that and see how it behaves without monitoring and decide from there.
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.
Split the test to explicitly test both normal and abnormal caller exits. Decided to keep the monitoring around because I think canceling the request if there is no caller to receive it is the right thing to do. I'll document this behavior in
async_request/3
, so that folks know that the caller must stick around for the request to continue. I can imagine some potentially useful patterns around this behavior, e.g.