You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I am very happy to use this crate but there are some problems with flush. Since logging is happened in another thread we can lose some data when main thread terminated (if there are data in channel or non flushed data in appenders). In my opinion log::logger.flush() should wait until channel is empty and every appender flush data.
The text was updated successfully, but these errors were encountered:
Sorry for misunderstanding. If there are some messages in channel and we stop main thread all that messages wipe out. So we need mechanism to wait until all messages sent to workers.
Sorry for misunderstanding. If there are some messages in channel and we stop main thread all that messages wipe out. So we need mechanism to wait until all messages sent to workers.
After log::logger().flush() is executed, it is actually a channel push WaitGroup message wrapped inside fast_log, and then crossbeam::WaitGroup waits for all waitgroups to be processed drop. So log::logger().flush() can be called on the main thread and wait until all messages are consumed
Hi, I am very happy to use this crate but there are some problems with flush. Since logging is happened in another thread we can lose some data when main thread terminated (if there are data in channel or non flushed data in appenders). In my opinion log::logger.flush() should wait until channel is empty and every appender flush data.
The text was updated successfully, but these errors were encountered: