3 ms·

If you think prints can't interfere with thread execution you're very, very wrong.

• rcxdude 4y ago
  It is substantially less interference than debuggers though (especially if you use async logging). On a lot of embedded systems hitting a breakpoint means the system will not function when execution continues.
  • maccard 4y ago
    I don't work on embedded systems so I can't comment on that particular kind of work. Interference is still interference though, and while debugging things that are susceptible to this kind of interference you need to be very clear about what you know you can rely on and what may be wrong. Relying on printing to not interfere is not possible. At best it's more reliable, in my average experience it's about as reliable, and in the worst case it's the same and both are broken. > especially if you use async logging If you are async logging then pretty much all of this goes out the window though. Firstly is your formatting async or does it happen when the message is enqueued? Message formatting is expensive, and the longer the message the more expensive it is to format. If you're dealing with low performance devices, you can definitely expect this overhead to adjust the performance and timings of your code. Running printf("%s\n") on a 1MB JSON blobis going to mess everything up, for example. Secondly, assuming that problem is resolved, you still need to order the messages to be printed. There is absolutely no guarantee that two messages sent at the same time from two different threads will be printed in the same order unless you enforce that through some other primitives - at that point see above.