> I've been using this as a review process of sorts. There's enough > divergence in places that I have to understand it pretty well to move > it over. :)
Yeah ;) had the same fun merging down. Just realized I forgot to build test on openbsd - I'll do that shortly. Can't add my machine to the buildbot yet because running it at 100% CPU too long hardlocks it. > In dev, we have three such loops now so I'd kind of like to refactor > it a bit to reuse the iterator and I'd kind of like to make the depth > of each configurable. The triple loop is weird, but I resisted refactoring... The biggest temptation is to simply add a flag so we only call the alloc routine again if we actually expire something. It's that and/or rolling the other loop into the first loop and automatically killing stuff that's locked for 3 hours, instead of just when the tail gets too full. I wrote it that way since it was the smallest chance of adding bugs... Uhhhhm. Want to add a command to inspect the tail. Then we can monitor for this condition, as well as the average search depth on allocation. Think that's worth adding to one of the main repos? Otherwise making the search depth configurable is a little silly, since there'll be no common way for folks to know if it helps at all. > I kind of like that this makes me more resistant to the temptation > of creating a command to increment the reference counter to make > objects `sticky.' :) Jeez, yeah :) Thanks! -Dormando
