On 16 July 2014 05:55, Ben Pfaff <b...@nicira.com> wrote: > > The kernel shouldn't ever return EAGAIN if there's more data to dump. > When dumping is single-threaded (as in branch-1.11) or serialized (as > post-commit 0791315e4d), the kernel implements that correctly. When > dumping is multithreaded, the kernel has races that screw it up, and > each thread can get EAGAIN if it loses a race. (I tried to explain > this in the commit message for commit 0791315e4d.) I'm pretty sure > that this is OK because that's how OVS worked throughout the whole OVS > 1.x series. >
Thanks for explaining. Is it worth commenting this assumption in the code? > * Current master, if a different error code is returned, will store the > > error code and stop dumping. This code appears to fall through and > continue > > reading from the buffer. Maybe the '0' is meant to be 'error'? > > Oops. Yes. > > I think that the other return could just pass along EAGAIN instead of > converting it to EPROTO. > That sounds fine. > EOF has a negative value (which is guaranteed by ANSI C and by POSIX), > normally -1 (but that part isn't guaranteed). > Now I know :-) _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
