On Sat, Apr 19, 2014 at 6:05 PM, dormando <[email protected]> wrote:
> > > > Once I wrapped my head around it, figured this one out. This cheap patch > "fixes" the test, although I'm not sure it is the best actual solution. > Because we don't set the lru_crawler_running flag on the main thread, but > in the LRU thread itself, we have a race condition here. pthread_create() > is by no means required to actually start the thread right away or > > schedule it, so the test itself asks too quickly if the LRU crawler is > running, before the auxiliary thread has had the time to mark it as > running. The sleep ensures we at least give that thread time to start. > > > > (Debugged by way of adding a print to STDERR statement in the while(1) > loop. The only time I saw the test actually pass was when that loop caught > and repeated itself for a while. It failed when it only ran once, which > would make sense if the thread hadn't actually set the flag yet.) > > Ahh okay. Weird that you're able to see that, as the crawl command signals > the thread. Hmm... no easy way to tell if it *had* fired or if it's not > yet fired. > > The parts I thought really hard about seem to be doing okay, but the > scaffolding I apparently goofed fairly bad, heh. > > I just pushed another commit to the crawler_fix tree, can you try it and > see if it works with an unmodified test? > We're good to go now, as far as I can tell. Ran the LRU test about 10 times on both machines I've been using today and it works every time now; no problems with the full test suite at this point either. -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
