Question about async and Windows

[HEnquist]

I have a question about the Async mode and the Windows terminal. I'm trying to solve an issue that comes when running my dsp app in the Windows terminal. This works fine, but if I grab the scrollbar, then the terminal blocks new input. And this in turn makes the logging calls block until the scrollbars is released. This makes my application stop all processing. I thought that the Async mode of flexi-logger would make the logging calls nonblocking, but while experimenting I got the same blocking behavior anyway. As soon as something prints to the terminal, everything halts. I have tried playing around with the different WriteModes, but doesn't seem to make much difference. When playing with Buffering, it runs until it's time to flush and then halts. Both with and without Async. Is there a workaround for this, or am I just misunderstanding something?

[emabee]

So far, the the Async mode of flexi-logger only has an effect for file-logging (that's also documented). But I see, at least for windows it would make sense to spend the effort also for stdin/stderr.

[HEnquist]

Thanks for the reply! Then I know why it didn't work as I expected. I checked again and yes it does say so in the documentation. I don't think it makes any difference for Linux and Macos, but the Windows terminal is a bit strange. A little Async for stderr/stdout would be a great addition!

[emabee]

Since there is some need, I'm working on it these days :-)

[HEnquist]

Sounds great! I'm using slog now but would love to switch to something leaner.

[emabee]

0.18.1 implements WriteMode::Async also for stdout and stderr.

This now ensures that your program keeps running, also if you grab the scrollbar, select some text, etc. Interestingly, Windows is now not capable anymore to block the program from writing. No clue why, and how to resolve this. I had expected that the output thread would be blocked, while the worker threads would happily build a huge backlog for the writer, until the output is unblocked again.

[HEnquist]

Just tried this new version, works great! Thanks a lot for implementing this :)

Interestingly, Windows is now not capable anymore to block the program from writing. No clue why, and how to resolve this. I had expected that the output thread would be blocked, while the worker threads would happily build a huge backlog for the writer, until the output is unblocked again.

I have a loop that logs several messages per second, and I use the async mode to stderr. If I grab the scrollbar, the output in the terminal stops. Then when I release it again I get all the messages that were logged while I was holding the bar. This is exactly what I wanted to happen! I don't see any problem here, but I'm probably misunderstanding something :)

[emabee]

Looks like I had over-flooded the console with output (the test did nothing else than writing logs), I repeated the test now with far less output per second, and now I can also freeze the console, and get the blocked output when I unfreeze it. Perfect!!