approve

All CLA requirements met.

Looks racy -- more on-demand initialization, and without data dependency..

Generic fix is to put all the state behind one pointer, that goes from null to non-null, once.

@jaykrell how is it racy? it's behind a lock...

1. Why is try/finally preferred? Do you want retry upon failure, or sticky failure, and is failure well handled either way? Try/finally makes failure sticky. I should read the code more.

2. The reads are not behind a lock?

if (inited)
{
  use foo;
}
else
{
  lock
  {
     foo = …
     inited = true
  }

is racy if foo is not a pointer (or the use does not dereference, such as compare to null or print).

1. Why is try/finally preferred? Do you want retry upon failure, or sticky failure, and is failure well handled either way? Try/finally makes failure sticky. I should read the code more.

In the original code, an exception on initialisation may fail to fully initialise, but will leave the class in an initialised state (since inited = true will always be set). After I've moved the inited = true statement to the end of the block, the addition of try/finally retains that behaviour.

2. The reads are not behind a lock?

From what I can see, all reads and writes to the uninitialised class will be gated at the lock until the class is initialised. After inited = true, the lock is not considered for any further operations, so it's a transient gate and is almost insignificantly short lived. I admit there's some racy-ness here, but all of it would have existed before my changes.

I did consider refactoring the class, but I think that would be a separate issue given the greater surface area.

I think it's fine for the issue @nagytech is trying to solve. I agree that refactoring is a separate effort.

The code is racy, and fails as a result, and the fix is to keep it racy, just less so? Is that right?

@jaykrell

The code is racy, and fails as a result, and the fix is to keep it racy, just less so? Is that right?

In general, yes. But, more specifically I would say that there are two distinct behaviours here:

1. The initialisation of TermInfoDriver is racy, and fails as a result, and the fix is to remove the racy aspect of the initialisation - which I've done; and

2. The post-initialized behaviour of TermInfoDriver is racy, and the fix would be best dealt with separately.

@monojenkins build failed

@monojenkins backport 2019-12