-
Notifications
You must be signed in to change notification settings - Fork 3k
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
ESP8266 - fix send buffer exhaustion handling #9309
Conversation
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.
Just one optional improvement noticed.
ret = NSAPI_ERROR_OK; | ||
} | ||
|
||
END: |
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.
Instead of using the goto statement, the ifs above could be transformed into an if - else if - else if structure.
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.
Duly noted, but I'll keep the original for now.
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.
I kind of like the goto END
type of handling where we have multiple cases which all should lead to shared error handling.
Its like try { ... } catch { ... } finally { ... }
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 a previous life, I worked with do { ... } while (false)
. I've always had mixed feelings about it.
@VeijoPesonen, thank you for your changes. |
tr_debug("ESP8266::send(): connection disrupted"); | ||
} | ||
|
||
if (!_sock_i[id].open) { |
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.
Must actually be if (!_sock_i[id].open && ret != NSAPI_ERROR_OK) {
|
||
if (_error) { | ||
ret = NSAPI_ERROR_CONNECTION_LOST; | ||
tr_debug("ESP8266::send(): connection disrupted"); |
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.
is this actually true?
Should we test that socket is actually closed? We should know that, because OOBs are already handled.
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.
Should we test that socket is actually closed?
That is done on the next if-clause.
If the connection cannot be established or gets
disrupted during data transmission, the system
returns:
ERROR
From the documentation.
So the question is can there occur an ERROR without socket being closed...
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.
Ah.. true.. Thanks.
Driver must return NSAPI_ERROR_WOULD_BLOCK if a server won't accept data from the modem and the modem's buffers are full. In case that socket is closed driver returns NSAPI_ERROR_CONNECTION_LOST.
Fixed my own review finding. |
CI started |
Test run: SUCCESSSummary: 11 of 11 test jobs passed |
Description
Driver must return NSAPI_ERROR_WOULD_BLOCK if a server won't accept
data from the modem and the modem's buffers are full. In case that
socket is closed driver returns NSAPI_ERROR_CONNECTION_LOST.
Pull request type
Reviewers
@ARMmbed/mbed-os-ipcore