Re: Questions about using qemuProcess API within a libvirt test

On 2/10/20 10:01 PM, Collin Walling wrote: Apart from what Laine said, this looks like your test binary is missing event loop. The way sending QMP commands work is that you have one thread, that wants to send a QMP command. It will construct the command, format JSON string out of it and notifies the other thread (where the event loop is running) and goes to sleep. The other thread waits until QMP socket becomes writable (poll()) and then writes the JSON string into it. Then it waits until the socket becomes readable and when it does so, it reads incoming data (which is a reply to the command). Once the full reply was received it will wake up the original thread [1]. Adding an event loop to your program should be easy. Just see what tests/qemucapsprobe.c is doing. Important bits are eventLoop() function and virEventRegisterDefaultImpl() and virThreadCreate() calls. However, as Laine says, we don't want our test suite to spawn any qemu process. Not only it would create a non-reproducible environment for the tests (developers might run different version of qemu), it might also not work at all - when building libvirt we don't require qemu to be installed (as we don't link with it, there is no library to link with anyways). But we want our test suite to run successfully. When we want to test something that talks on QMP monitor (e.g. qemumonitorjsontest), we create two threads and provide an alternative implementation for the event loop - instead of actually touching any real QMP monitor socket, it discards all writes, and provides well defined replies (crafted before). Look into the source file and you will understand. Michal 1: In fact, the event loop always poll()-s for socket to be readable, because QEMU can send us an event asynchronously, but let's not complicate things right now.