Expand JSON buffer lock scope to entire web reply #3648
Conversation
Add JSONBufferGuard, an RAII lock guard class for JSONBufferLock analogous to std::lock_guard. This permits binding the guard to a scope, such as an object life cycle or function body, guaranteeing that the lock will be released when the scope exits.
Extend the JSON response class to hold the global JSON buffer lock until the transaction is completed. Fixes Aircoookie#3641
Ensure we delete the response if it's not locked
Expand JSON buffer lock scope to entire web reply
Expand JSON buffer lock scope to entire web reply
Expand JSON buffer lock scope to entire web reply
|
is it possible to have this kind of problem even after update? |
|
Buffer reuse has been solved by this PR. |
Expand JSON buffer lock scope to entire web reply
|
I had a broken JSON for this so I solved in this way |
|
@WAPEETY presets have no connection with this issue. Presets are always served "as is" from the file system. |
|
wait so it has anything to do about the fact that I was recieving a broken JSON from the presets? |
…nse-locking" This reverts commit cdc8640.
|
It took me quite a while to get here, and I wonder if nobody else discovered this yet: This patch completely destroys the performance, at least on an ESP8266. Easy to check: Up to 0.14.1-b2 (d1-mini, 160 MHz), getting constant 23 FPS (even 25 FPS with 0.13.*). Copying json.cpp from 0.14.1-b2 to 0.14.1-b3 restores the 23 FPS. Can anybody check this please, and confirm? |
|
Any function in Otherwise it has no influence on FPS. |
When generating a JSON reply, ensure that the global JSON buffer isn't released until the response is completely ack'd by the client. This fixes some cases where the JSON reply exceeded a single packet and the second packet was corrupted by later users of the global buffer overwriting some of the packet data.
Fixes #3641