http://lists.freedesktop.org/archives/libreoffice/2012-April/029940.html
The RTL_USING #define (set by gbuild for anything that's not public
API) allows to use such classes simply by their name, without having
to use the namespace or do explicit using rtl::OUString (which half
of the sources do anyway).
Change-Id: I7edaf12cd278489cdc1d5ff782f0a86361c13c0a
This is a follow up to d015384e1d "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:
* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.
That has been addressed by giving Bridge::dispose new semantics: It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined. (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)
* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.
That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock. (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)
* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.
That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.
Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f
Unfortunately this --enable-dbg-util only problem (caused by
_GLIBCXX_DEUBG) resurfaced, perhaps because of new std::string based
logging in sal; adapt all map files to export the unique symbol.
At least with sw_complex test under load, it happened that an ORequestThread
could still process a remote release request while the main thread was already
in exit(3). This was because (a) ThreadPool never joined with the spawned
worker threads (which has been rectified by calling uno_threadpool_dispose(0)
from the final uno_threadpool_destroy), and (b) binaryurp::Bridge called
uno_threadpool_destroy only from its destructor (which could go as late as
exit(3)) instead of from terminate.
Additional clean up:
* Access to Bridge's threadPool_ is now cleanly controlled by mutex_ (even
though that might not be necessary in every case).
* ThreadPool's stopDisposing got renamed to destroy, to make meaning clearer.
Change-Id: I45fa76e80e790a11065e7bf8ac9d92af2e62f262
this removes dmake completely out of the build for migrated modules
build.pl now assumes modules to be gbuild, unless there is a
prj/dmake file
Change-Id: I674a036b182ee13c5ec093e83cb3d38133112d3b
(This reverts commit 0ba6bd3ddc025666a6d4bb0640bf443728b23bd3.)
The problems worked-around there are no longer observed by me, so they
were hopefully only a temporal problem (the real root cause had never
been found back then). If problems start to pop up again, we'll need
to have another look at this.
Naming convention for gbuild methods:
- "add" is used for stuff that is logically a part of the target
(i.e. not registered at the Module, but defined in the target's makefile)
- "use" is used for stuff that is logically a different target
(i.e. it is registered at the Module, has it's own makefile, may be
in a different module than the target)
...which has the necessary features to support it.
Change a lot of classes to either contain a protected non-virtual dtor
(which is backwards compatible, so even works for cppumaker-generated
UNO headers) or a public virtual one.
cppuhelper/propertysetmixin.hxx still needs to disable the warning, as
the relevant class has a non-virtual dtor but friends, which would still
cause GCC to warn.
Includes a patch for libcmis, intended to be upstreamed.
SAL_UNUSED_PARAMETER (expanding to __attribute__ ((unused)) for GCC)
is used to annotate legitimately unused parameters, so that static
analysis tools can tell legitimately unused parameters from truly
unnecessary ones. To that end, some patches for external modules
are also added, that are only applied when compiling with GCC and
add necessary __attribute__ ((unused)) in headers.
They are virtually unused (at least the LibO code base has only a
single use of UNO_REF_QUERY) but confuse static analysis tools that
classify unused function parameters as "tags" (which legalizes the
unusedness of those parameters) if they are of an enum type with
exactly one value defined.
* New build prerequisite doxygen (controllable via --with-doxygen).
* Adapted various headers to slightly different doxygen documentation
syntax, but much clean up still remains to be done (i.e., warnings
emitted by doxygen fixed).
* New SAL_INFO..., SAL_WARN... macros.
* New SAL_STREAM supersedes OSL_FORMAT.
* oustringostreaminserter.hxx moved from unotest to rtl (and always UTF-8 now).
* TODO to enable GCC __attribute__((format)) in sal/log.h (requires call-site
cleanup).
* Further functionality in tools/debug.hxx (DBG_MEMTEST, DBG_CTOR, etc.) not yet
addressed.
* Some replacements tools String -> rtl::OUString.
We can't build it here at this point during the build after all. We
use static linking on iOS, and we would need to link with -lgcc3_uno
from bridges which has not been built yet. It seems that any
meaningful unit tests for iOS actually need to be built in a
"subsequent" stage.
Nah, having them behind dbglevel>1 is fine (which already means these
assertions won't normally be compiled even with --enable-debug).
I got mislead as I was building with dbglevel=2 everywhere. But
pondering the point of dbglevel a.k.a. OSL_DEBUG_LEVEL, I think the
right way to see it is: You are not supposed to build all (or large
parts) of LibreOffice with dbglevel=2. If we used OSL_TRACE all over
the place as thoroughly as in some files in sal/rtl, that would lead
to astronomical amounts of tracing output. (We don't use OSL_TRACE
like that, but that is another thing...)
I think the intended use of dbglevel is that you should build with
dbglevel=2 only the small part of code you are currently actively
working on, when you want to see trace output.
Of course, another problem then is that in some modules and/or
libraries it might not be possible to compile just a part of the
sources with dbglevel=2. That should be fixed.
This reverts commit a3bad28550.
