Dragon2fly/logger_tt

Logs are not printed prettily in interactive shell

Closed this issue · 6 comments

after calling setup_logging, printing logs in interactive shell may result in >>> in front of some of the lines.
image

and the last line can sometimes be lost if I input new texts

Hi @ZeroRin

There are two kinds of output here. One is from the interactive shell ('>>>' and your typing) and one is from the logger handling thread.

Due to the thread processing nature, the output of the logger is not continuous.
While the logger is printing or waiting for data on the queue, the os may switch back to the interactive shell thread and it prints out >>>.

For the loss of the last log line, I can only assume the race condition between the interactive shell thread and the logger thread.

So is it a problem for you or what are you trying to archive?

Just trying to print logs in interactive shell just as the default StreamHandler does, but still keeping the configurations in my log_config.json. Maybe I can try to extract all the handlers from LogConfig and replace the QueueHandler with them?

Since LogConfig replaces all handlers with QueueHandler, I think it is easier to stop that from happening with a flag.
i.e. pass a parameter to setup_logging and edit the method _set_mode.

saw that the logging doc says the module is thread-safe, so I just need to avoid calling _replace_with_queue_handler in single-processing mode there?

I added the following code in my logging startup and the behavior in interactive shell is as desired now.

class SPLogConfig(LogConfig):
    def _set_mode(self, use_multiprocessing):
        if not use_multiprocessing:
            pass
        else:
            super()._set_mode(use_multiprocessing)

logger_tt.internal_config = SPLogConfig()

Yes. Anyway, it is intended to be thread-safe, not 100% sure it is. For normal usage, it shouldn't be a problem.

If what you are doing in the interactive console is simple, execute a short command and wait for all logs to be printed before entering a new one, that is the way to do it.

If the command output an enormous amount of log, you may experience a long waiting time before your command is completed.