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.

Sign up for GitHub

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

Jump to bottom

fix(esockd_transport): make it work with OTP 26 #181

Merged
merged 3 commits into from
Oct 13, 2023
Merged

fix(esockd_transport): make it work with OTP 26 #181

merged 3 commits into from
Oct 13, 2023

Conversation

zmstone
Copy link
Member

@zmstone zmstone commented Oct 13, 2023

No description provided.

@zmstone zmstone force-pushed the 1013-fix-port-command-for-otp-26 branch from 1acbdee to 3b304e2 Compare October 13, 2023 13:39
@zmstone
fix(otp26): fix SSL compatibility for OTP 26
4b85060 
There is no need to add appup instructions for changed modules
because they are only type spec changes
@zmstone zmstone merged commit e150e09 into master Oct 13, 2023
8 checks passed
@zmstone zmstone deleted the 1013-fix-port-command-for-otp-26 branch October 13, 2023 15:23
zmstone added a commit to zmstone/emqx that referenced this pull request Jun 4, 2024
@zmstone
perf: eliminate the loop-back fake async inet_reply message
1e9da7e 
Now that EMQX is on OTP 26 by default, the fake inet_reply
message when the send call returns ok only adds overhead.

For TCP (gen_tcp module), OTP 26 no longer supports direct port_command
so we had to swith to gen_tcp:send, then fake an async reply:
see emqx/esockd#181

For TLS (ssl module), it has never supported async send anyway.

This commit switches to call Transport:send/2 directly,
this should result in one less loop-back message for each message.

For OTP 25 on which EMQX can still be compiled, one will have to
suffer the performance penalty for gen_tcp:send function to
do a non-optimized 'receive' for the send result.
@zmstone zmstone mentioned this pull request Jun 4, 2024
Merged
9 tasks
zmstone added a commit to zmstone/emqx that referenced this pull request Jun 4, 2024
@zmstone
perf: eliminate the loop-back fake async inet_reply message
0dc2be1 
Now that EMQX is on OTP 26 by default, the fake inet_reply
message when the send call returns ok only adds overhead.

For TCP (gen_tcp module), OTP 26 no longer supports direct port_command
so we had to swith to gen_tcp:send, then fake an async reply:
see emqx/esockd#181

For TLS (ssl module), it has never supported async send anyway.

This commit switches to call Transport:send/2 directly,
this should result in one less loop-back message for each message.

For OTP 25 on which EMQX can still be compiled, one will have to
suffer the performance penalty for gen_tcp:send function to
do a non-optimized 'receive' for the send result.
zmstone added a commit to zmstone/emqx that referenced this pull request Jun 4, 2024
@zmstone
perf: eliminate the loop-back fake async inet_reply message
6f5610f 
Now that EMQX is on OTP 26 by default, the fake inet_reply
message when the send call returns ok only adds overhead.

For TCP (gen_tcp module), OTP 26 no longer supports direct port_command
so we had to swith to gen_tcp:send, then fake an async reply:
see emqx/esockd#181

For TLS (ssl module), it has never supported async send anyway.

This commit switches to call Transport:send/2 directly,
this should result in one less loop-back message for each message.

For OTP 25 on which EMQX can still be compiled, one will have to
suffer the performance penalty for gen_tcp:send function to
do a non-optimized 'receive' for the send result.
zmstone added a commit to zmstone/emqx that referenced this pull request Jun 5, 2024
@zmstone
perf: eliminate the loop-back fake async inet_reply message
7eb4e7d 
Now that EMQX is on OTP 26 by default, the fake inet_reply
message when the send call returns ok only adds overhead.

For TCP (gen_tcp module), OTP 26 no longer supports direct port_command
so we had to swith to gen_tcp:send, then fake an async reply:
see emqx/esockd#181

For TLS (ssl module), it has never supported async send anyway.

This commit switches to call Transport:send/2 directly,
this should result in one less loop-back message for each message.

For OTP 25 on which EMQX can still be compiled, one will have to
suffer the performance penalty for gen_tcp:send function to
do a non-optimized 'receive' for the send result.
zmstone added a commit to zmstone/emqx that referenced this pull request Jun 5, 2024
@zmstone
perf: eliminate the loop-back fake async inet_reply message
44ebd74 
Now that EMQX is on OTP 26 by default, the fake inet_reply
message when the send call returns ok only adds overhead.

For TCP (gen_tcp module), OTP 26 no longer supports direct port_command
so we had to swith to gen_tcp:send, then fake an async reply:
see emqx/esockd#181

For TLS (ssl module), it has never supported async send anyway.

This commit switches to call Transport:send/2 directly,
this should result in one less loop-back message for each message.

For OTP 25 on which EMQX can still be compiled, one will have to
suffer the performance penalty for gen_tcp:send function to
do a non-optimized 'receive' for the send result.
zmstone added a commit to zmstone/emqx that referenced this pull request Jun 5, 2024
@zmstone
perf: eliminate the loop-back fake async inet_reply message
41ad46d 
Now that EMQX is on OTP 26 by default, the fake inet_reply
message when the send call returns ok only adds overhead.

For TCP (gen_tcp module), OTP 26 no longer supports direct port_command
so we had to swith to gen_tcp:send, then fake an async reply:
see emqx/esockd#181

For TLS (ssl module), it has never supported async send anyway.

This commit switches to call Transport:send/2 directly,
this should result in one less loop-back message for each message.

For OTP 25 on which EMQX can still be compiled, one will have to
suffer the performance penalty for gen_tcp:send function to
do a non-optimized 'receive' for the send result.
zmstone added a commit to zmstone/emqx that referenced this pull request Jun 6, 2024
@zmstone
perf: eliminate the loop-back fake async inet_reply message
2525bd0 
Now that EMQX is on OTP 26 by default, the fake inet_reply
message when the send call returns ok only adds overhead.

For TCP (gen_tcp module), OTP 26 no longer supports direct port_command
so we had to swith to gen_tcp:send, then fake an async reply:
see emqx/esockd#181

For TLS (ssl module), it has never supported async send anyway.

This commit switches to call Transport:send/2 directly,
this should result in one less loop-back message for each message.

For OTP 25 on which EMQX can still be compiled, one will have to
suffer the performance penalty for gen_tcp:send function to
do a non-optimized 'receive' for the send result.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@qzhuyan qzhuyan qzhuyan approved these changes

@thalesmg thalesmg thalesmg approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
3 participants
@zmstone @qzhuyan @thalesmg