On 1/22/12 2:41 PM, Alan M. Carroll wrote:
I got stuck for a week on a regression test failure while trying to fix TS-1077. I eventually tracked it down to NetVCOptions::frequent_accept defaulting to true instead of false. Checking the source control logs it turns out that I had it as false when I first checked in the main patch, but then tweaked it back to true in a minor fixup patch. I can, of course, no longer recall why I thought I needed to change that. Looking at the 2.1.7 codebase it seems that prior to the NetVCOptions change, the value was passed explicitly as false everywhere except for testing code and examples. The symptoms were that the accepted socket would be marked as IO read ready right after the accept even though there was no data on available. The main IO loop would then read it, get 0 bytes, and close it. After I changed the default to false, regression passed and I am currently doing successful live testing.
Hmmm, this sounds awefully familiar, I think we had this exact problem once before as well, and I changed it back to "true" as it used to be.
I thought we wanted "frequent_accept" to be true at all time. If not, e.g. accept threads would not be available at all.
I don't know why I haven't seen this effect before, as the default change was almost 5 months ago. 1) Is there any evidence that the default for frequent_accept (that is, use fastAccept) should remain true instead of false (do not use)? 2) Should we just get rid of the fast accept path if it is only used in examples and testing?
I'm a little confused I think. Looking at the code, frequent_accept also enables accept threads, and accept per thread. Unless I'm totally wrong, I think we should get rid of this "flag", but we ought to keep the code path as if the flag was true (which the current code base does). Hearing that it breaks your regression is alarming.
-- leif
