On 1/9/2014 22:40, Nicholas Clark wrote:
On Thu, Jan 09, 2014 at 10:32:37PM +0100, Jonathan Worthington wrote:
Hi,
On 1/9/2014 22:00, Nicholas Clark wrote:
I've been running with the appended for a few weeks now, and I think that
it's the right fix.
Unfortunately, releasing the mutex at this point leads to a race
condition. In f5171fe5 I've committed a fix that should avoid the
deadlock *and* not introduce a race. Trying the committed fix out under
hg would be most welcome, if you've a moment to do so.
Bother. I wasn't aware of the race.
Took me a few looks through to convince myself it was one. :-)
Sadly I think that it's going to be tricky to recreate the problem on
hellgrind. In that, it was during the sequence of builds where I was reducing
the nursery run size by 1K each time, and hence causing nursery GC runs to
happen in different places. In this case, the GC run just happened to be at
exactly the wrong/right time to trigger this.
But I can't see a good way to recreate a GC run at exactly this point* and
then proving that nothing happens. And hellgrind is terribly terribly slow,
so it's not practical to run with each for each reducing nursery size.
Well, the point of the patch is that we ensure there's *not* a GC run at
that point. So falsely creating one won't actually help anything.
* without modifying the code - so is that the answer?
1) Modify the code to force a GC run at this point.
2) Locally revert the patch. Confirm that hellgrind is unhappy
3) Wind back the reversion. Confirm that hellgrind is happy
4) Profit!
Well, maybe, but now I ponder it more, even this doesn't cut it, as
previous SC allocations don't go in the nursery, so the GC will trigger
at a different point, so...ugh.
So yes, "tricky to recreate" indeed, and probably not worth the effort
at all. Sorry for failing to send you on a wild goose chase. :-)
Jonathan
