On Sat, Aug 14, 2010 at 11:11:40AM -0600, Eric Blake wrote: >> First of all, for me, the call to recvfrom returns 0, even though the >> buffer actually is populated with the response from the monitor. > I'm not sure about this one. The recvfrom is called in a loop, and > POSIX says that recvfrom shall return the size if a message was read, or > 0 if no messages were available but the other end of the connection did > an orderly shutdown. Yes, it does. That's part of why it took me so long to figure out. I really didn't expect data to come back when recvfrom returned 0 :) > I think we need a bit more understanding of why you are getting a 0 return, > and whether it only happens after a successful iteration of the loop (in > which case the contents of res are leftover from the prior iteration). Unless multiple threads are reading from the fd (?), I'm quite confident in my data. I dumped the whole monitor_response buffer right before and right after the recvfrom call along with the return value of recvfrom. I'll rerun the tests tomorrow and show you the results. If my results are accurate and it is indeed a kernel bug (well, or eglibc or whatnot), I believe it's in the spirit of libvirt to accept that one of the other parts of the equation is doing something silly and work around it. :) I'm happy to provide more evidence, though. I'm not sure if I pointed this out in my initial e-mail, but even if I didn't have this recvfrom problem, the check seems odd to my eye. Is the monitor really going to send a max sized datagram each time? I would have expected it to only send a datagram the size of the header + the length of the data. -- Soren Hansen <soren@xxxxxxxxxxx> Systems Architect, The Rackspace Cloud Ubuntu Developer -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list