Luni-4

I still do not have a perfect definition, but I would like to pass the async timer as an asynchronous closure to the `recv_timeout()` which uses that internally. But I...

Closing due to #401 discussion

@fabiensanglard You might add your answers to the `mdns-sd` documentation. Choose the place that it seems the most appropriate for you to detect this information at first glance. In the...

Ah, I see, thanks! But since `receiver` is a re-exported method from `flume`, we have a different [documentation](https://docs.rs/flume/latest/flume/struct.Receiver.html#method.recv_timeout). Is it possible to achieve the same result as in `flume`?

Exactly, since `receiver` is the same in `mdns-sd` and in `flume`, they should **not** behave differently. But these two loops ```rust /// mdns-sd while let Ok(event) = receiver.recv_timeout(Duration::from_secs(5)) { println!("{:?}",...

Ok, it’s clearer now — thank you! I modified my `flume` code to verify the behaviour more precisely, and it matches the `mdns-sd` code. ```rust use std::time::Duration; #[async_std::main] async fn...

I will give it a try! Thank you! Closing since it is invalid!

@nathanielsimard @antimora @syl20bnr @laggui @louisfd I would like to have your opinion on this issue

I have always used `tracing` in libraries as well for the `async` advantages, but if we want to let developers choose their preferred logger implementations, yep, `log` is better. >...

Looking through the code, the `log` functions are used directly in the necessary `burn` crates, while the `log` dependency is handled by the workspace. Therefore, we do not need to...