Re-init ServiceRegistry on every Initialize() call

[ausbin]

Without this, the sequence of calls

xacc::Initialize()
xacc::Finalize()
xacc::Initialize()

will cause CppMicroservices to throw the following:

terminate called after throwing an instance of 'std::runtime_error'
  what():  The bundle context is no longer valid

Testing

I ran ctest and did some end-to-end testing with QIR-EE.

[danclaudino]

Thanks @ausbin. This seems such an edge case. I'm curious when one would ever use/need the following.

xacc::Initialize()
xacc::Finalize()
xacc::Initialize()

[sethrj]

release gives up the pointer for someone else to hold on to (in this case, it's leaking memory). I think you want reset or = {} or = nullptr.

[ausbin]

Thanks, will fix.

I also will look into why the tests are segfaulting. I wonder if something is accessing the service registry after finalize()

[ausbin]

Good point @danclaudino. Is that sequence of calls even supported? I assumed so, but if you are only supposed to call xacc::Initialize() and xacc::Finalize() once per process (understandable), then we should fix QIR-EE instead. Because right now, XaccQuantum in QIR-EE calls xacc::Initialize() and xacc::Finalize() each time it is constructed and destructed (respectively)

If this is meant to be supported, I will investigate the Python segfault further (I looked a bit and some Python code is indeed touching the ServiceRegistry before xacc::Initialize()). Otherwise, I will close this PR.

[sethrj]

This seems such an edge case. I'm curious when one would ever use/need the following.

xacc::Initialize()
xacc::Finalize()
xacc::Initialize()

@danclaudino Is the expectation that you only execute one quantum circuit for every use of XACC? Or that you're supposed to assume that you're the only library in a larger toolchain that uses XACC (and thus only your library will ever call init/finalize)? If Finalize doesn't finalize, why bother having it at all? Maybe it would be better to just "initialize" the global variables once and then have an if (initialized) return; in the initialize function to prevent subsequent errors.

The usual reason to have multiple initialize/finalize is to reset states for reproducibility, unit testing, etc.

[danclaudino]

Good point @danclaudino. Is that sequence of calls even supported?
I assumed so, but if you are only supposed to call xacc::Initialize() and xacc::Finalize() once per process (understandable), then we should fix QIR-EE instead. Because right now, XaccQuantum in QIR-EE calls xacc::Initialize() and xacc::Finalize() each time it is constructed and destructed (respectively)

If this is meant to be supported, I will investigate the Python segfault further (I looked a bit and some Python code is indeed touching the ServiceRegistry before xacc::Initialize()). Otherwise, I will close this PR.

This has probably flown under the radar since it's hard to imagine a case where the sequence you pointed out would come up when using XACC, thus it being an edge case. But I think there shouldn't be any fundamental reason for it not to be supported.

[danclaudino]

@sethrj

@danclaudino Is the expectation that you only execute one quantum circuit for every use of XACC?

No. In principle you can execute as many circuits as you want.

Or that you're supposed to assume that you're the only library in a larger toolchain that uses XACC (and thus only your library will ever call init/finalize)?

This is probably the case. I'm not familiar with the inner workings of xacc::Initialize() and xacc::Finalize(), but it seems they will likely need some rethinking in order to work in the intended way.