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.

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

Switch to willmmiles fork of AsyncWebServer (0_15) #3741

Closed
wants to merge 14 commits into from

Conversation

willmmiles
Copy link
Member

As for #3740, but on 0_15.

Switch WLED to use the willmmiles fork of AsyncWebServer, with the following improvements:

  • Merge some open PRs from upstream
  • Fix longstanding use-after-free in AsyncWebServerRequest::_removeNotInterestingHeaders
  • Move many static strings to PROGMEM, reducing RAM usage by ~1k
  • Add a simple response queue, reducing peak RAM usage
    • Note: this is not a hard limit unfortunately - memory usage is still unbounded with a SYM flood or large POST, as I have yet to find a practical solution to throttle inbound traffic.
  • Some small reductions in allocator usage during operation

This should be considered an alpha-quality work in progress; I'm offering it here for early testing and feedback. Version number is not pinned yet.

@willmmiles willmmiles force-pushed the 0_15-willmmiles-webserver branch 4 times, most recently from be361b9 to 48a5e4f Compare February 20, 2024 03:10
Enable concurrent request and queue size limit features of the
willmmiles fork of AsyncWebServer.  This should reduce the risk of
OOM crashes.
Release the json buffer lock as soon as we've finished serializing.
This should slightly reduce the number of lock collisions as the
response class isn't destructed until after the last packet is ack'd.
It's not permissible to call delay during AsyncWebServer callbacks, and
it doesn't help on single-core systems.  Add a quick exit path for these
cases.
Use the web server's queuing mechanism to call us back later.
Make the low heap debugging messages stand out more in a trace.
These were mostly PROGMEM already, but every little bit helps.
Rather than relying on the exception handler, indicate the
__FlashStringHelper type so the correct String constructor is
used.
Eliminate the extra indirection and allocate shared buffers directly.
@willmmiles willmmiles force-pushed the 0_15-willmmiles-webserver branch from 48a5e4f to 1e82c13 Compare February 21, 2024 20:43
@willmmiles
Copy link
Member Author

Closing this one - I think it'll be better managed in smaller updates.

@willmmiles willmmiles closed this Feb 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant