On Thu, 2014-02-27 at 23:30 -0600, Andrew Deason wrote: > As for what is triggering this behavior, as far as I can tell it's > just > a normal short read from the fssync socket. That is, one side sends > 292 > bytes, and the other receives 200 bytes (and then would receive > another > 92 bytes if it continued reading). The code currently expects that > reads > and writes on the socket will complete with a single read/write call. > We > "should" account for the case where that does not happen, but I'm not > sure of why that would ever indeed not happen. (These are all very > short > requests on a unix domain socket whose internal buffer cannot be > anywhere near full.)
Sometimes things like this are introduced just to catch out broken code (linux has occasionally done this!). You're not supposed to rely on stuff like that, and there are the odd cases where it might happen even when what you might think it's safe to assume it won't. (Also it doesn't really have a normal fixed buffer, IIRC on the *BSDs it's all mbuf chains and IIRC it can combine two short mbufs instead of underusing a larger one in some circumstances. Each mbuf will then be returned by a separate read.) -- brandon s allbery kf8nh sine nomine associates [email protected] [email protected] unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net :�� T���&j)b� b�өzpJ)ߢ�^��좸!��l��b��(���~�+����Y���b�ا~�����~ȧ~
