We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
If client end dies, accept_stream hangs with a {quic, closed, Conn} message in the message queue. A possible fix is:
{quic, closed, Conn}
accept_stream(Conn, Opts, Timeout) when is_list(Opts) -> accept_stream(Conn, maps:from_list(Opts), Timeout); accept_stream(Conn, Opts, Timeout) when is_map(Opts) -> % @todo make_ref % @todo error handling NewOpts = maps:merge(default_stream_opts(), Opts), case quicer_nif:async_accept_stream(Conn, NewOpts) of {ok, Conn} -> receive {quic, new_stream, Stream} -> {ok, Stream}; {quic, closed, Conn} -> {error, connection_closed} after Timeout -> {error, timeout} end; {error, _} = E -> E end.
The text was updated successfully, but these errors were encountered:
thanks for reporting.
Your solution will help if caller process is the owner of both connection and the stream so it will recv 'events' from both connection and stream.
I think we need a signal to inform the stream acceptor that the connection is closed in resource dtor.
something like the todo in https://github.com/emqx/quic/blob/main/c_src/quicer_nif.c#L639
Sorry, something went wrong.
qzhuyan
Successfully merging a pull request may close this issue.
If client end dies, accept_stream hangs with a
{quic, closed, Conn}
message in the message queue.A possible fix is:
The text was updated successfully, but these errors were encountered: