| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We now specialize std::less<const std::type_info*> to use
std::type_info::before(), and on Windows and Mac that Just Works. It even
works on Linux when using gcc 4.4+: more recent implementations of gcc's
std::type_info::before() apparently do name()-string comparisons internally.
It doesn't work so well on Linux with gcc 4.1, though, and that's the compiler
we still use on our Linux build-farm machines. But rather than give up,
perform explicit name()-string comparison in that case.
|
|
Instead of forbidding std::map<const std::type_info*, ...> outright (which
includes LLRegistry<const std::type_info*, ...> and LLRegistrySingleton<const
std::type_info*, ...>), try to make it work by specializing std::less<const
std::type_info*> to use std::type_info::before().
Make LLRegistryDefaultComparator<T> use std::less<T> so it can capitalize on
that specialization.
|
|
|
|
The changeset above touched every consumer of the two LLRegistrySingletons
originally defined with std::type_info* as keys. Those two
LLRegistrySingletons were changed to use const char* as keys, then all
consumers were changed to pass std::type_info::name() instead of the plain
std::type_info* pointer -- to deal with the observed fact that on Linux, a
given type might produce different std::type_info* pointers in different load
modules. Since then, Richard turned up the fascinating fact that at least some
implementations of gcc's std::type_info::before() method already accommodate
this peculiarity. It seems worth backing out the (dismayingly pervasive)
change to see if properly using std::type_info::before() as the map comparator
will work just as well, with conceptually simpler source code.
This backout is transitional: we don't expect things to build/run properly
until we've cherry-picked certain other pertinent changes.
|
|
boost::unordered_map<const char*, ...> does NOT, by default, "do the right
thing." Give it hash and equality functors that do.
|
|
Try to diagnose the cause of the misbehavior with a BOOST_STATIC_ASSERT.
|
|
|
|
Although LLRegistry and LLRegistrySingleton have always defined a COMPARATOR
template parameter, it wasn't used for the underlying map. Therefore every
type, including any pointer type, was being compared using std::less. This
happens to work most of the time -- but is tripping us up now.
Pass COMPARATOR to underlying std::map. Fix a couple minor bugs in
LLRegistryDefaultComparator (never before used!). Specialize for const char*.
Remove CompareTypeID and LLCompareTypeID because we now actively forbid using
LLRegistry<std::type_info*, ...>; remove only known reference
(LLWidgetNameRegistry definition).
|
|
Per discussion with Richard, accept the type key for insert() and find() as a
template parameter rather than as std::type_info*. This permits (e.g.) some
sort of compile-time prehashing for common types, without changing the API.
Eliminate iterators from the API altogether, thus avoiding costs associated
with transform_iterator.
Fix existing references in llinitparam.h.
|
|
Back out code that selects LLTypeInfoLookup for the underlying map
implementation when KEY = [const] std::type_info*, because LLTypeInfoLookup's
API is changing to become incompatible with std::map. Instead, fail with
STATIC_ASSERT when LLRegistry's KEY is [const] std::type_info*.
Fix all existing uses to use std::type_info::name() string instead.
|
|
Maybe it's failing to correctly handle overloaded transform() methods?
|
|
It seems MSVC doesn't like boost::make_transform_iterator() in the context I
was using it. Try directly invoking the iterator's constructor.
|
|
The original LLTypeInfoLookup implementation was based on two assumptions:
small overall container size, and infrequent normal-case lookup failures.
Those assumptions led to binary-searching a sorted vector, with linear search
as a fallback to cover the problem case of two different type_info* values for
the same type. As documented in the Jira, this turned out to be a problem. The
container size was larger than expected, and failed lookups turned out to be
far more common than expected.
The new implementation is based on a hash map of std::type_info::name()
strings, which should perform equally well in the success and failure cases:
no special-case fallback logic.
|
|
textures to checkerboards
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
testing mode.
|
|
|
|
|
|
|
|
The change from LLProcessLauncher to LLProcess introduces the possibility of a
NULL (default-constructed) LLProcessPtr. Add certain static LLProcess methods
accepting LLProcessPtr, forwarding to nonstatic method when non-NULL but doing
something reasonable with NULL. Use these methods in LLPLuginProcessParent.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Now LLProcess explicitly requests APR to limit the handles passed to any child
process, instead of wantonly passing whatever happens to be lying around the
parent process at the time.
This requires the latest APR build.
Also revert LLUpdateDownloader::Implementation::mDownloadStream to llofstream
(as in rev 1878a57aebd7) instead of apr_file_t*. Using APR for that file was a
Band-Aid -- a single whacked mole -- for the problem more systemically
addressed by apr_procattr_constrain_handle_set().
|
|
|
|
llphysicsextension library.
|
|
|
|
|
|
On Windows, calling CreateProcess(bInheritHandles=FALSE) is the wrong idea. In
that case, CreateProcess() passes NO handles -- even the files you've
explicitly designated as the child's stdin, stdout, stderr in the STARTUPINFO
struct! Remove LLProcess code to tweak bInheritHandles; we should also remove
the corresponding (useless) APR extension.
Instead, given that the Windows file-locking problem we've observed is
specific to the viewer installer .exe file downloaded by the background
updater logic, use APR file I/O for that specific file. Empirically, both
llofstream and std::ofstream seem to make the open file handle inheritable;
but apr_file_open() documentation says: "By default, the returned file
descriptor will not be inherited by child processes created by
apr_proc_create()." And indeed, it does appear to sidestep the locking problem.
|
|
That is, when the underlying LLError::Settings object is destroyed -- possibly
at termination, possibly on LLError::restoreSettings() -- the passed Recorder*
is deleted.
There was much existing code that seemed as unaware of this alarming fact as I
was myself. Passing to addRecorder() a pointer to a stack object, or to a
member of some other object, is just Bad. It might be preferable to make
addRecorder() accept std::auto_ptr<Recorder> to make the ownership transfer
more explicit -- or even boost::shared_ptr<Recorder> instead, which would
allow the caller to either forget or retain the passed Recorder.
This preliminary pass retains the Recorder* dumb pointer API, but documents
the ownership issue, and eliminates known instances of passing pointers to
anything but a standalone heap Recorder subclass object.
|
