Two sleep() methods: one accepting F32Milliseconds, or in general any LLUnits
time class; the other accepting any std::chrono::duration.
The significant thing about each of these sleep() methods, as opposed to any
freestanding sleep() function, is that it only sleeps until the app starts
shutdown. Moreover, it returns true if it slept for the whole specified
duration, false if it woke for app shutdown.
This is accomplished by making LLApp::sStatus be an LLScalarCond<EAppStatus>
instead of a plain EAppStatus enum, and by making setStatus() call set_all()
each time the value changes. Then each new sleep() method can call
wait_for_unequal(duration, APP_STATUS_RUNNING).
Introducing llcond.h into llapp.h triggered an #include circularity because
llthread.h #included llapp.h even though it didn't reference anything from it.
Removed. This, in turn, necessitated adding #include "llapp.h" to several .cpp
files that reference LLApp but had been depending on other header files to
drag in llapp.h.
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.
Using a Params block gives compile-time checking against attribute typos. One
might inadvertently set myLLSD["autofill"] = false and only discover it when
things behave strangely at runtime; but trying to set myParams.autofill will
produce a compile error.
However, it's excellent that the same LLProcess::create() method can accept
either LLProcess::Params or a properly-constructed LLSD block.
LLProcessLauncher had the somewhat fuzzy mandate of (1) accumulating
parameters with which to launch a child process and (2) sometimes tracking the
lifespan of the ensuing child process. But a valid LLProcessLauncher object
might or might not have ever been associated with an actual child process.
LLProcess specifically tracks a child process. In effect, it's a fairly thin
wrapper around a process HANDLE (on Windows) or pid_t (elsewhere), with
lifespan management thrown in. A static LLProcess::create() method launches a
new child; create() accepts an LLSD bundle with child parameters. So building
up a parameter bundle is deferred to LLSD rather than conflated with the
process management object.
Reconcile all known LLProcessLauncher consumers in the viewer code base,
notably the class unit tests.
Ansariel