Can't really flush an async logger, as it can't not control the receiver on the other side of a channel.

The closest thing we could have is maybe waiting for the channel to empty. But I'm not sure if we should.

Generally displaying password prompts via logging is not a good idea. One should be using stderr for that, or some completely different things altogether.

Jeah sure. I guessed that its kind of tricky, waiting till the channel has emptied is close, but probably still no guaranteed that the underlaying drains have been flushed... only the channel is empty...

Thanks for the response. I find another solution.

Ah. I'm silly. You are logging with slog-async, and then you might want to display prompt etc. on stderr . It seems like a legitimate use case...

Under the hood we are using

It does support is_empty(): https://docs.rs/crossbeam-channel/latest/crossbeam_channel/struct.Sender.html#method.is_empty

So i guess we (I mean... you, if you care enough to submit a PR :D ) could add a new method to the trait / API that would attempt to "flush" (e.g. wait until is_empty() == true with some polling interval). If it's a trait, add a default impl that just return a custom IO error "unsupported" for backward compat.

@Techcable for awareness.

Yes, you understood that correctly. Yes, sounds interesting to have a look at over the weekend. Thanks for pointing into the directions! If there are more thoughts let me know.

@dpc: Some question for undestanding the problem better: Do you think it makes sense to make a new trait Flushable which a Drain instance can have where it would implement flush in lib slog/lib.rs.
And then make an implementation for Async as you suggested =).

Thanks alot

Ah maybe its better to add this functionality to the Drain with a default implementation?

Most ecosystem expects Drain already, so it would have be a new method on an existing trait with an default impl that does something reasonable (like signals lack of support for flushing).