On Tue, Feb 15, 2022 at 1:01 PM Peter Maydell <[email protected]> wrote: > > On Tue, 15 Feb 2022 at 17:46, John Snow <[email protected]> wrote: > > Just so I don't leave this thread hanging, I filed a GitLab issue and > > I'm working on it, but this one isn't as quick to solve as the other. > > > > https://gitlab.com/qemu-project/qemu/-/issues/874 > > Is there anything particular to NetBSD that means it happens > more often there, or is it just random luck that we hit > the race there and haven't seen it elsewhere ? > > -- PMM
Complete random luck, something jostled loose by the scheduler. I need to change the interface in the async library entirely to make the process more granular -- We don't need the granularity in a truly async mode, but the sync wrapper that allows the existing iotests corpus to use the library in a synchronous manner *requires* a more granular connection API, so I have to write one. It's in progress, it just might be a few more days; verifying and testing the error pathways has been slow work. (In detail: python's asyncio.create_unix_server() call combines bind() + listen() + accept() into a single discrete step. A synchronous client, though, needs to have a reprieve from all of those blocking steps to launch the QEMU process after listen() but before accept() so it can launch the QEMU process. I was able to pull the bind() step out, but the async listen() + accept() steps the way I initially wrote it are inseparable. Live and learn.) In the meantime, there *IS* a way to use the old library, but I don't think the environment variable in question is routed down into the VM tests. I can look at (as a very quick fix) amending the VM launcher to pass along that environment variable if it sees it set in the host environment -- that should get you on the old, tried-and-true library when you want it, and the test should pass. --js
