mathieucarbou
commented
3 months ago @mathieucarbou , Can you check this with your application. Apparently, I don't have any good example which is using multiple cores. I expect a few artifacts like combined printing but that should be OK considering application stops crashing.
Looking at the diff, 100% sure it will solve the issue. The issue was the busy loop waiting for a flag that was never coming, so the TWDT of my tasks elsewhere were triggered because all the cpu was reserved to the webserial code.
So removing this busy will fix any WD issue.
In my app, I do not log from both cores: I only log from core 1, to avoid any issue (already tried in the past and it was messing up badly in the HardwareSerial).
So like you said, the worst that can happen is 2 tasks on the same core that are logging, and then buffering, and the logs get interleaved.
The only way to solve that is to use a buffering on caller side (that's what I have in my logger library, a buffer, which is only sent once finished).
My high perf impl (without buffering) is not affected since the caller buffer is sent directly to the WS layer. And if the buffer option is activated for the high perd mode, to handle printf, write(c), etc, then, since it is a shared buffer, it is still subject to interleaved logs but in a really limited way since I am flushing the buffer as soon as the EOL appears. So to get interleaved logs, it would require someone to do a printf() which is not finished, then a delay or yield, then a write(c) or printf. Something that is not likely to happen since most of the use cases are to stream logs...
@mathieucarbou , Can you check this with your application. Apparently, I don't have any good example which is using multiple cores. I expect a few artifacts like combined printing but that should be OK considering application stops crashing.