-
Notifications
You must be signed in to change notification settings - Fork 7.4k
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
fix(asyncudp): Fixes and implements tcpip thread locking #10415
fix(asyncudp): Fixes and implements tcpip thread locking #10415
Conversation
👋 Hello HamzaHajeir, we appreciate your contribution to this project! Click to see more instructions ...
Review and merge process you can expect ...
|
Memory usage test (comparing PR against master branch)The table below shows the summary of memory usage change (decrease - increase) in bytes and percentage for each target.
Click to expand the detailed deltas report [usage change in BYTES]
|
Test Results 56 files - 59 56 suites - 59 4m 12s ⏱️ - 30m 21s Results for commit 848b0ae. ± Comparison against base commit 733373a. This pull request removes 9 and adds 2 tests. Note that renamed tests count towards both.
♻️ This comment has been updated with latest results. |
@@ -473,12 +485,13 @@ bool AsyncUDP::_init() { | |||
if (_pcb) { | |||
return true; | |||
} | |||
UDP_MUTEX_LOCK(); | |||
_pcb = udp_new(); | |||
if (!_pcb) { | |||
return false; |
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.
Shouldn't there be an unlock before the return?
Well spotted, missed to consider that path. Now should I add another commit
or amend the commit?
…On Fri, Oct 4, 2024, 11:48 TD-er ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In libraries/AsyncUDP/src/AsyncUDP.cpp
<#10415 (comment)>
:
> @@ -473,12 +485,13 @@ bool AsyncUDP::_init() {
if (_pcb) {
return true;
}
+ UDP_MUTEX_LOCK();
_pcb = udp_new();
if (!_pcb) {
return false;
Shouldn't there be an unlock before the return?
—
Reply to this email directly, view it on GitHub
<#10415 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AH3O7J2WS6AW55EUKMG375LZZZI63AVCNFSM6AAAAABPJS4YGOVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDGNBXGQ4TCNBRHA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
just add another commit to this PR |
Done |
Hello @HamzaHajeir, please sign CLA without that we are not able to merge this PR. Thanks! |
That bureaucratic :) Couldn't find that document, can you guide how to? |
See the 2nd post in this PR: #10415 (comment) |
Thanks, done! |
Description of Change
Implements and fixes TCPIP Core locking in AsyncUDP when enabled.
AsyncUDP calls Raw LwIP APIs that are not safe to call from other threads without locking. While some raw APIs are being called by using
tcpip_api_call()
, other calls are not considering this method, as [1], [2], [3], and [4].When
CONFIG_LWIP_CHECK_THREAD_SAFETY
is enabled, the system gets aborted when the lwip core is not locked; Therefore exposing a source of bugs.Any call to
tcpip_api_call()
in tcpip core locked results in a deadlock, thus removed the corresponding calls.I've prefered to check against the state before locking and unlocking, helpful when any concerned AsyncUDP API being called from within LwIP thread, highly through callbacks, if any.
This will not affect the direct Arduino users but until esp32-arduino-libs-builder PR gets merged it will fix a source of bugs.
Currently: Arduino-as-ESPIDF-component users can easily have this fix by enabling
CONFIG_LWIP_TCPIP_CORE_LOCKING
option.Related links
https://www.nongnu.org/lwip/2_1_x/multithreading.html
#10391 (comment)