Longtime fans will remember that the "dcoroutine" library is a Google Summer
of Code project by Giovanni P. Deretta. He originally called it
"Boost.Coroutine," and we originally added it to our 3p-boost autobuild
package as such. But when the official Boost.Coroutine library came along
(with a very different API), and we still needed the API of the GSoC project,
we renamed the unofficial one "dcoroutine" to allow coexistence.
The "dcoroutine" library had an internal low-level API more or less analogous
to Boost.Context. We later introduced an implementation of that internal API
based on Boost.Context, a step towards eliminating the GSoC code in favor of
official, supported Boost code.
However, recent versions of Boost.Context no longer support the API on which
we built the shim for "dcoroutine." We started down the path of reimplementing
that shim using the current Boost.Context API -- then realized that it's time
to bite the bullet and replace the "dcoroutine" API with the Boost.Fiber API,
which we've been itching to do for literally years now.
Naturally, most of the heavy lifting is in llcoros.{h,cpp} and
lleventcoro.{h,cpp} -- which is good: the LLCoros layer abstracts away most of
the differences between "dcoroutine" and Boost.Fiber.
The one feature Boost.Fiber does not provide is the ability to forcibly
terminate some other fiber. Accordingly, disable LLCoros::kill() and
LLCoprocedureManager::shutdown(). The only known shutdown() call was in
LLCoprocedurePool's destructor.
We also took the opportunity to remove postAndSuspend2() and its associated
machinery: FutureListener2, LLErrorEvent, errorException(), errorLog(),
LLCoroEventPumps. All that dual-LLEventPump stuff was introduced at a time
when the Responder pattern was king, and we assumed we'd want to listen on one
LLEventPump with the success handler and on another with the error handler. We
have never actually used that in practice. Remove associated tests, of course.
There is one other semantic difference that necessitates patching a number of
tests: with "dcoroutine," fulfilling a future IMMEDIATELY resumes the waiting
coroutine. With Boost.Fiber, fulfilling a future merely marks the fiber as
ready to resume next time the scheduler gets around to it. To observe the test
side effects, we've inserted a number of llcoro::suspend() calls -- also in
the main loop.
For a long time we retained a single unit test exercising the raw "dcoroutine"
API. Remove that.
Eliminate llcoro_get_id.{h,cpp}, which provided llcoro::get_id(), which was a
hack to emulate fiber-local variables. Since Boost.Fiber has an actual API for
that, remove the hack.
In fact, use (new alias) LLCoros::local_ptr for LLSingleton's dependency
tracking in place of llcoro::get_id().
In CMake land, replace BOOST_COROUTINE_LIBRARY with BOOST_FIBER_LIBRARY. We
don't actually use the Boost.Coroutine for anything (though there exist
plausible use cases).
Longtime fans will remember that the "dcoroutine" library is a Google Summer
of Code project by Giovanni P. Deretta. He originally called it
"Boost.Coroutine," and we originally added it to our 3p-boost autobuild
package as such. But when the official Boost.Coroutine library came along
(with a very different API), and we still needed the API of the GSoC project,
we renamed the unofficial one "dcoroutine" to allow coexistence.
The "dcoroutine" library had an internal low-level API more or less analogous
to Boost.Context. We later introduced an implementation of that internal API
based on Boost.Context, a step towards eliminating the GSoC code in favor of
official, supported Boost code.
However, recent versions of Boost.Context no longer support the API on which
we built the shim for "dcoroutine." We started down the path of reimplementing
that shim using the current Boost.Context API -- then realized that it's time
to bite the bullet and replace the "dcoroutine" API with the Boost.Fiber API,
which we've been itching to do for literally years now.
Naturally, most of the heavy lifting is in llcoros.{h,cpp} and
lleventcoro.{h,cpp} -- which is good: the LLCoros layer abstracts away most of
the differences between "dcoroutine" and Boost.Fiber.
The one feature Boost.Fiber does not provide is the ability to forcibly
terminate some other fiber. Accordingly, disable LLCoros::kill() and
LLCoprocedureManager::shutdown(). The only known shutdown() call was in
LLCoprocedurePool's destructor.
We also took the opportunity to remove postAndSuspend2() and its associated
machinery: FutureListener2, LLErrorEvent, errorException(), errorLog(),
LLCoroEventPumps. All that dual-LLEventPump stuff was introduced at a time
when the Responder pattern was king, and we assumed we'd want to listen on one
LLEventPump with the success handler and on another with the error handler. We
have never actually used that in practice. Remove associated tests, of course.
There is one other semantic difference that necessitates patching a number of
tests: with "dcoroutine," fulfilling a future IMMEDIATELY resumes the waiting
coroutine. With Boost.Fiber, fulfilling a future merely marks the fiber as
ready to resume next time the scheduler gets around to it. To observe the test
side effects, we've inserted a number of llcoro::suspend() calls -- also in
the main loop.
For a long time we retained a single unit test exercising the raw "dcoroutine"
API. Remove that.
Eliminate llcoro_get_id.{h,cpp}, which provided llcoro::get_id(), which was a
hack to emulate fiber-local variables. Since Boost.Fiber has an actual API for
that, remove the hack.
In fact, use (new alias) LLCoros::local_ptr for LLSingleton's dependency
tracking in place of llcoro::get_id().
In CMake land, replace BOOST_COROUTINE_LIBRARY with BOOST_FIBER_LIBRARY. We
don't actually use the Boost.Coroutine for anything (though there exist
plausible use cases).
LLInstanceTracker<T> performs validation in ~LLInstanceTracker(). Normally
validation failure logs an error and terminates the program, which is fine. In
the test executable, though, we want validation failure to throw an exception
instead so we can catch it and continue testing other failure conditions. But
since destructors in C++11 are implicitly noexcept(true), that exception never
made it out of ~LLInstanceTracker(): it crashed the test program instead.
Declaring ~LLInstanceTracker() noexcept(false) solves that, allowing the test
program to catch the exception and continue.
However, if we unconditionally declare that, then every destructor anywhere in
the inheritance hierarchy for any LLInstanceTracker subclass must also be
noexcept(false)! That's way too pervasive, especially for functionality we
only need (or want) in a specific test executable.
Instead, make the CMake macros LL_ADD_PROJECT_UNIT_TESTS() and
LL_ADD_INTEGRATION_TEST() -- with which we define all viewer build-time tests
-- define two new command-line macros: LL_TEST=testname and LL_TEST_testname.
That way, preprocessor logic in a header file can detect whether it's being
compiled for production code or for a test executable.
(While at it, encapsulate in a new GET_OPT_SOURCE_FILE_PROPERTY() CMake macro
an ugly repetitive pattern. The builtin GET_SOURCE_FILE_PROPERTY() sets the
target variable to "NOTFOUND" -- rather than an empty string -- if the
specified property wasn't set. Every call to GET_SOURCE_FILE_PROPERTY() in
LL_ADD_PROJECT_UNIT_TESTS() was followed by a test for NOTFOUND and an
assignment to "". Wrap all that in a macro whose 'unset' value is "".)
Now llinstancetracker.h can detect when we're building the LLInstanceTracker
unit test executable, and *only then* declare ~LLInstanceTracker() as
noexcept(false). We #define LLINSTANCETRACKER_DTOR_NOEXCEPT to expand either
empty or noexcept(false), also detecting clang in C++11 mode. (It all works
fine without noexcept(false) until we turn on C++11 mode.)
We also use that macro for the StatBase class in lltrace.h. Turns out some of
the infrastructure headers required for tests in general, including the
LLInstanceTracker test, use LLInstanceTracker. Fortunately that appears to be
the only other class we must annotate this way for the LLInstanceTracker tests.
Cmake files not merged correctly and had to be done by hand. New memory
allocation made some memory usage tests in the llcorehttp integration
tests no longer valid. Would like to work on LLLog sometime and get
it to be consistent. Special flags needed for windows build of example
program.
Ansariel