> On Dec 18, 2025, at 5:33 PM, Timur Tabi <[email protected]> wrote: > > On Thu, 2025-12-18 at 22:27 +0900, Alexandre Courbot wrote: >>>> + loop { >>>> + match >>>> cmdq.receive_msg::<UnloadingGuestDriverReply>(Delta::from_secs(5)) { >>>> + Ok(resp) => return Ok(resp), >>>> + Err(ERANGE) => continue, >>>> + Err(e) => return Err(e), >>>> + } >>> >>> This outer loop can go on infinitely, lets bound it? >>> >>> Either outer timeout or bounded number of tries. Bounded tries better since >>> it has inner >>> timeout. >> >> Yes. And what we really want is a more generic way to do this, because >> this pattern occurs with several commands so far (and more to come). > > Isn't the real problem that we are polling for a specific message, when all > message should be > handled asynchronously as events, like Nouveau does? > > Err(ERANGE) => continue, > > This effectively throws out all other messages, including errors and anything > else important. >
Indeed, for that we need Interrupts. For the rest of the patterns where we need the message synchronously, we should bound this. Hanging in the driver is unacceptable. Interrupts are almost here now, considering we/others have upstreamed all the required patches for Rust interrupt support.
