Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
I just asked myself the question why it seems generally accepted to block when writing to stdout or stderr. Most tokio examples just use std::print! which is a blocking call. Also the log crate as well as the tracing crate, which is connected to tokio and made to be used in async code, only have sync apis. Is there any explanation why? Is it just general acceptance because this is just the most ergonomic way? Especially if piping stdout somewhere print calls might block a long time and logging to files might do so too. Are there any good logging crates (optimally using tokio) which don't require sync calls to be inserted everywhere. In my current project blocking because of some flush to persistent memory isn't really acceptable but i still would like to log and trace events. Thanks for your time and have a nice day.
I just asked myself the question why it seems generally accepted to block when writing to stdout or stderr. Most tokio examples just use std::print! which is a blocking call. Also the log crate as well as the tracing crate, which is connected to tokio and made to be used in async code, only have sync apis. Is there any explanation why? Is it just general acceptance because this is just the most ergonomic way? Especially if piping stdout somewhere print calls might block a long time and logging to files might do so too. Are there any good logging crates (optimally using tokio) which don't require sync calls to be inserted everywhere. In my current project blocking because of some flush to persistent memory isn't really acceptable but i still would like to log and trace events. Thanks for your time and have a nice day.