viewer.git - Megapahit's fork of the Second Life viewer.

Age	Commit message (Collapse)	Author
2012-02-13	Use per-frame ticks on "mainloop" LLEventPump to update LLProcess.	Nat Goodspeed
	When we reimplemented LLProcess on APR, necessitating APR's funny callback mechanism to sense child-process status, every isRunning() or getStatus() call called the APR poll function that calls ALL registered LLProcess callbacks. In other words, every time any consumer called any LLProcess::isRunning() method, all LLProcess callbacks were redundantly fired. Change that so that the single APR poll function is called once per frame, courtesy of the "mainloop" LLEventPump. Once per viewer frame should be well within the realtime duration in which it's reasonable to expect child-process status to change. In effect, this changes LLProcess's public API to introduce a dependency on "mainloop" ticks. Add such ticks to llprocess_test.cpp as well.
2012-02-13	Suppress a specific unused-var warning on Posix platforms.	Nat Goodspeed

2012-02-09	Remove LLJob class: apr_procattr_autokill_set() should now handle.	Nat Goodspeed
	LLJob was vestigial code from before migrating Job Object support into APR. Also add APR signal-name string to getStatusString() output.
2012-02-07	LLProcess::Status enum values need qualification in helper function.	Nat Goodspeed

2012-02-07	Convert LLProcess implementation from platform-specific to using APR.	Nat Goodspeed
	Include logic to engage Linden apr_procattr_autokill_set() extension: on Windows, magic CreateProcess() flag must be pushed down into apr_proc_create() level. When using an APR package without that extension, present implementation should lock (e.g.) SLVoice.exe lifespan to viewer's on Windows XP but probably won't on Windows 7: need magic flag on CreateProcess(). Using APR child-termination callback requires us to define state (e.g. LLProcess::RUNNING). Take the opportunity to present Status, capturing state and (if terminated) rc or signal number; but since most of the time all caller really wants is to log the outcome, also present status string, encapsulating logic to examine state and describe exited-with-rc vs. killed-by-signal. New Status logic may report clearer results in the case of a Windows child process killed by exception. Clarify that static LLProcess::isRunning(handle) overload is only for use when the original LLProcess object has been destroyed: really only for unit tests. We necessarily retain our original platform-specific implementations for just that one method. (Nonstatic isRunning() no longer calls static method.) Clarify log output from llprocess_test.cpp in a couple places.
2012-01-30	Set bit flag on CreateProcess() to allow AssignProcessToJobObject().	Nat Goodspeed
	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.
2012-01-30	LLProcess::handle must be qualified when used in LLJob class.	Nat Goodspeed

2012-01-30	Expose 'handle' as well as 'id' on LLProcess objects.	Nat Goodspeed
	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.
2012-01-30	Trim trailing "\r\n" from Windows FormatMessage() string for logging.	Nat Goodspeed

2012-01-27	On Windows, only quote LLProcess arguments if they seem to need it.	Nat Goodspeed
	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.
2012-01-23	Per Richard: close unusable Job Object; move quote() to LLStringUtil.	Nat Goodspeed
	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.
2012-01-22	Every singleton needs a friend...	Nat Goodspeed

2012-01-22	Add LLProcess logging on launch(), kill(), isRunning().	Nat Goodspeed
	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.
2012-01-22	Make LLProcess::Params streamable; use that in LLExternalEditor.	Nat Goodspeed

2012-01-22	On Windows, introduce viewer Job Object and assign children to it.	Nat Goodspeed
	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.
2012-01-20	Define LLProcess::Params; accept create(const LLSDParamAdapter<Params>&).	Nat Goodspeed
	This allows callers to pass either LLSD formatted as before -- which all callers still do -- or an actual LLProcess::Params block.
2012-01-20	Per Richard, replace LLProcessLauncher with LLProcess.	Nat Goodspeed
	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.