| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Windows 7 and friends tend to create a process already implicitly allocated to
a job object, and a process can only belong to a single job object. Passing
CREATE_BREAKAWAY_FROM_JOB in CreateProcessA()'s dwCreationFlags seems to
bypass the access-denied error observed with AssignProcessToJobObject()
otherwise.
This change should (!) enable OS lifespan management for SLVoice.exe et al.
|
|
|
|
|
|
On Posix, these and the corresponding getProcessID()/getProcessHandle()
accessors produce the same pid_t value; but on Windows, it's useful to
distinguish an int-like 'id' useful to human log readers versus an opaque
'handle' for passing to platform-specific API functions. So make the
distinction in a platform-independent way.
|
|
|
|
On Posix platforms, the OS argument mechanism makes quoting/reparsing
unnecessary anyway, so this only affects Windows.
Add optional 'triggers' parameter to LLStringUtils::quote() (default: space
and double-quote). Only if the passed string contains a character in
'triggers' will it be double-quoted.
This is observed to fix a Windows-specific problem in which plugin child
process would fail to start because it wasn't expecting a quoted number.
Use LLStringUtils::quote() more consistently in LLProcess implementation for
logging.
|
|
|
|
|
|
That is, we try to pass through each args entry as a separate child-process
arvg[] entry, whitespace and all.
|
|
|
|
If LLProcess can't set the right flag on a Windows Job Object, the object
isn't useful to us, so we might as well discard it.
quote() is sufficiently general that it belongs in LLStringUtil instead of
buried as a static helper function in llprocess.cpp.
|
|
|
|
|
|
Much as I dislike viewer log spam, seems to me starting a child process,
killing it and observing its termination are noteworthy events.
New logging makes LLExternalEditor launch message redundant; removed.
|
|
|
|
The idea is that, with the right flag settings, this will cause the OS to
terminate remaining viewer child processes when the viewer terminates --
whether or not it terminates intentionally. Of course, if LLProcess's caller
specifies autokill=false, e.g. to run the viewer updater, that asserts that we
WANT the child to persist beyond the viewer session itself.
|
|
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.
|
|
This allows callers to pass either LLSD formatted as before -- which all
callers still do -- or an actual LLProcess::Params 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.
|
|
by everyone
|
|
moved LLInitParam, and LLRegistry to llcommon
moved LLUIColor, LLTrans, and LLXUIParser to llui
reviewed by Nat
|
|
and LLBufferArray::copyIntoBuffers
|
|
|
|
|
|
Despite LLProcessLauncher's list-of-argument-strings API, on Windows it must
ram them all into a single command-line string anyway. This means that if
arguments contain spaces (or anything else that would confuse Windows command-
line parsing), the target process won't receive the intended arguments.
Introduce double quotes for any arguments not already double-quoted by caller.
|
|
names are disabled.
* Fixed LLAvatarName::getLegacyName() to work when display names are disabled
(it used to return ' ', i.e. empty first and last name separated with a space).
* Added some debugging messages.
|
|
Apparently our TeamCity build machines are still not up to Python 2.6.
|
|
|
|
typedef LLProcessLauncher::ll_pid_t to be HANDLE on Windows, pid_t elsewhere.
Then we can define getProcessID() returning ll_pid_t on all platforms,
retaining getProcessHandle() for hypothetical existing consumers... of which
there are none in practice.
This lets us define isRunning(ll_pid_t) to encapsulate the platform-specific
logic to actually check on a running child process, turning non-static
isRunning() into a fairly trivial wrapper.
|
|
|
|
Instead of free python() and python_out() functions containing a local
temporary LLProcessLauncher instance, with a 'tweak' callback param to
"do stuff" to that inaccessible object, change to a PythonProcessLauncher
class that sets up a (public) LLProcessLauncher member, then allows you to
run() or run() and then readfile() the output. Now you can construct an
instance and tweak to your heart's content -- without funky callback syntax --
before running the script.
Move all such helpers from TUT fixture struct to namespace scope. While
fixture-struct methods can freely call one another, introducing a nested class
gets awkward: constructor must explicitly require and bind a fixture-struct
pointer or reference. Namespace scope solves this.
(Truthfully, I only put them in the fixture struct originally because I
thought it necessary for calling ensure() et al. But ensure() and friends are
free functions; need only qualify them with tut:: namespace.)
|
|
Run INTEGRATION_TEST_llprocesslauncher using setpython.py so we can find the
Python interpreter of interest.
Introduce python() function to run a Python script specified using
NamedTempFile conventions.
Introduce a convention by which we can read output from a Python script using
only the limited pre-January-2012 LLProcessLauncher API. Introduce
python_out() function to leverage that convention.
Exercise a couple of LLProcessLauncher methods using all the above.
|
|
On a Posix platform (vfork()/execv() implementation), if for any reason the
execv() failed (e.g. executable not on PATH), the viewer would never know, nor
the user: the vfork() child produced no output, and terminated with rc 0! Add
logging, make child terminate with nonzero rc.
Remove pointless addArgument(const char*) overload: this does nothing for you
that the compiler won't do implicitly.
In llupdateinstaller.cpp, remove pointless c_str() call in addArgument() arg:
we were starting with a std::string, then extracting its c_str(), only to
construct a whole new std::string from it!
|
|
|
|
|
|
Specifically:
Introduce ManageAPR class in indra/test/manageapr.h. This is useful for a
simple test program without lots of static constructors.
Extract NamedTempFile from llsdserialize_test.cpp to indra/test/
namedtempfile.h. Refactor to use APR file operations rather than platform-
dependent APIs.
Use NamedTempFile for llprocesslauncher_test.cpp.
|
|
|
|
|
|
|
|
|
|
|
|
|
