traceback from hg serve

[James Gregory]

well 2.9.1 was already installed in /usr/local, so maybe even when
running the old hg in /usr/bin the lib dir was set such that it was
actually importing the files from 2.9.1 anyway.

As far as I am aware nothing is meant to be updating the config at
all, I think the requests from the continuous integration server are
all just "hg pull". I guess the "do_POST" in the traceback mean it's
occuring when one of the constant "hg pull" polls by the sever happens
to coincide with an "hg push" by someone adding changes to the
repository?

All the POST requests in the log are either "cmd=pushkey" or
"cmd=unbundle". A wild guess would be that maybe whenever someone uses
mercurial keyring to make a push it has a side effect of updating the
config, which causes problems if it coincides with an "hg pull"?

Does the GIL allow a thread context switch whenever a C library call
is made? If so then my previous statement about the GIL is nonsense,
as there are countless opportunities for context switching in just
about any code. I'm not a Python developer so I don't really know what
I'm talking about.

On 28 April 2014 22:11, Matt Mackall <mpm at selenic.com> wrote:
> On Mon, 2014-04-28 at 10:25 +0100, James Gregory wrote:
>> Actually, updating mercurial to 2.9.1 didn't fix the error, it just so
>> happened to not occur for an hour after making the upgrade.
>
> Hmm, your original backtrace line numbers lined up only with 2.9.x.
>
>>  Applying
>> the above patch also didn't make any difference. I have now changed
>> the line in config __init __ from:
>>
>> for k in data._data:
>>
>> to:
>>
>> for k in data._data.copy():
>>
>> to see if that helps, though I admit I have no real understanding of
>> what the code is actually doing. Being intermittent it kinds of looks
>> like it could be a concurrency bug,
>
> It's absolutely a concurrency bug. It's pretty hard to hit in my testing
> though.. I had a setup hitting hgweb 20-30 times per second and was only
> seeing the problem occur every 10 minutes or so.
>
> Mercurial generally handles concurrency by avoiding sharing objects
> read/write across threads (rather than locking). One place this isn't
> properly respected is in managing the global configuration. If we write
> to the global config (eg to turn off verbosity globally) while another
> thread is reading, things can break.
>
> --
> Mathematics is the supreme nostalgia of our time.
>
>



-- 
James