Re: [libvirt] [PATCH 3/3] Remove wrong check for uml monitor response size
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(a)linux2go.dk>
Systems Architect, The Rackspace Cloud
Ubuntu Developer