summaryrefslogtreecommitdiff
path: root/indra/llplugin/llpluginprocessparent.cpp
AgeCommit message (Collapse)Author
2019-01-14SL-10291 Replace apr_mutex with standard C++11 functionalityandreykproductengine
2016-01-15merge changes for 4.0.1-releaseOz Linden
2015-11-10Added code to initiate controlled shutdown of plugins with timeouts for ↵Rider Linden
misbeahving plugin.
2015-11-10remove execute permission from many files that should not have itOz Linden
2014-05-20MAINT-4009: Patching a leak of LLPluginSharedMemory objects from the ↵Stinson Linden
LLPluginProcessParent class.
2013-08-09second phase summer cleaningRichard Linden
replace llinfos, lldebugs, etc with new LL_INFOS(), LL_DEBUGS(), etc.
2013-04-19merge changes for DRTVWR-294Oz Linden
2013-03-29Update Mac and Windows breakpad builds to latestGraham Madarasz
2013-03-05Fixing issues with not detecting when LLSD XML parsing fails. Changing most ↵Don Kjer
http error handlers to understand LLSD error responses. Fleshing out most http error handler message spam.
2012-06-06MAINT-1144: Defend against NULL LLPluginProcessParent::mProcess.Nat Goodspeed
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.
2012-01-21Convert LLProcess consumers from LLSD to LLProcess::Params block.Nat Goodspeed
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.
2012-01-20Per 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.
2011-08-09EXP-700 WIP SLPlugin(s) takes high CPU%Richard Linden
clamp maximum framerate of slplugin to 100Hz also added assert to catch cases where we're requesting infinite framerate
2011-03-01SOCIAL-595 FIX Global Volume control does not affect volume of MOAP in ↵Richard Linden
minimal skin on Windows made slplugin.exe start with correct working directory (llplugin)
2011-02-08VWR-21275 FIX // *SOME* Windows systems fail to load the Qt plugins if the ↵callum
current working Reviewed by Richard - http://codereview.lindenlab.com/6011001/
2010-08-13Change license from GPL to LGPL (version 2.1)Oz Linden
2010-04-30Looks like the linux apr version is a bit too old to build 5458d58b4cd0. ↵Tofu Linden
Use this workaround for now.
2010-04-29Incorporate suggestions from Richard's review of the LLPlugin changes.Monroe Linden
Use LLMutexLock (stack-based locker/unlocker) for the straightforward cases instead of explicit lock()/unlock(). There are still a couple of cases (one overlapping lock lifetime and two loops that unlock the mutex to call another function inside the loop) where I'm leaving explicit lock/unlock calls. Rename LLPluginProcessParent::sPollThread to sReadThread, for consistency. Made the LLPluginProcessParent destructor hold mIncomingQueueMutex while removing the instance from the global list -- this should prevent a possible race condition in LLPluginProcessParent::poll(). Removed a redundant check when calling LLPluginProcessParent::setUseReadThread().
2010-04-27Architectural changes to LLPlugin message processing.Monroe Linden
LLPluginProcessParent can now optionally use a separate thread for reading messages from plugin sockets. If this is enabled, it will spawn a single thread and use apr_pollset_poll to wake up the thread when incoming data arrives instead of polling all the descriptors round-robin every frame. This should be somewhat more efficient, and should also allow blocking requests from plugins to be serviced much more quickly (once we start using them). This is currently disabled by default, until it's had a bit more focused testing on multiple platforms. Hooked up the switch to use the message read thread to the PluginUseReadThread debug setting and an item in the Advanced menu in the viewer, and to a checkbox in the UI in llmediaplugintest. Updated some debug logging in the plugin system to have appropriate tags and not log dire-looking warnings during normal operation. LLPluginProcessParent now once again explicitly kills plugin processes (instead of just closing their sockets and waiting for them to exit). The problem we were attempting to solve by not doing the kill (letting the webkit plugin write its cookie file on exit) has been solved another way. LLPluginProcessParent::sendMessage() now attempts to write the outgoing message to the socket immediately instead of waiting for the next frame. This should reduce the latency of sending plugin messages. Added a separate fast timer for LLViewerMedia::updateMedia().
2010-04-23Add a way for plugins to send a message and block waiting for the responseMonroe Linden
This requires some cooperation between the plugin and the host, and will only work for specific messages. The way it works is as follows: * the plugin sends a message containing the key "blocking_request" (with any value) * this will cause the "send message" function to block (continuing to pull incoming messages off the network socket and queue them) until it receives a message from the host containing the key "blocking_response" ** NOTE: if the plugin sends a blocking_request that isn't set up to cause the host to send back a blocking_response, it will block forever * the blocking_response message will be handed to the plugin's "receive message" function _immediately_ (before the "send message" function returns) ** this means that the plugin can extract response data for use by the the code that sent the message (but is still blocked inside the "send message" call) ** NOTE: this BREAKS the invariant stating that the plugin's "receive message" function will never be called recursively, and the plugin MUST be prepared to deal with this * after the plugin finishes processing the blocking_response message, the "send message" function that was called with the blocking_request message will return to the plugin * any queued messages will be delivered after the outer invocation of the plugin's "receive message" function returns (as normal) Inside the viewer, the code can tell when a plugin is in this blocked state by calling LLPluginProcessParent::isBlocked(). LLPluginClassMedia uses this to avoid sending mouse-move and size-change messages to blocked plugins.
2010-03-16Added an "init" message in LLPLUGIN_MESSAGE_CLASS_MEDIA, and made ↵Monroe Linden
LLPluginClassMedia queue it up before initializing its LLPluginProcessParent. Made all existing plugins send their texture_params message from this init message instead of the LLPLUGIN_MESSAGE_CLASS_BASE "init" message. (This ensures that they won't start to receive 'size_change' messages until after the init has happened.) Added "set_user_data_path" and "set_language_code" messages to LLPluginClassMedia. Made webkit plugin deal with the new messages, when they're sent before it receives the media "init". Removed the user_data_path and language_code arguments from the init function calls throughout the hierarchy. Made LLViewerMediaImpl queue up the language code and user data path messages before initializing the media. Reviewed by Callum at http://codereview.lindenlab.com/687006 .
2010-03-12(for B5) Fix for EXT-5823 "Include language in user-agent string" ↵Callum Prentice
(implemented via JavaScript - not in ua string) (for B5) Fix for EXT-5314 "Inworld Browser blanks out at credit card entry" Note: also includes an update to install.xml that points to a new version of LLQtWebKit that is required for these fixes
2010-02-03CID-262Tofu Linden
Checker: UNINIT_CTOR Function: LLPluginProcessParent::LLPluginProcessParent(LLPluginProcessParentOwner *) File: /indra/llplugin/llpluginprocessparent.cpp
2009-12-17Changed default launch timeout in LLPluginProcessParent to 60 seconds, and ↵Monroe Linden
added an to LLPluginProcessParent that allows callers to adjust the launch and lockup timeouts.
2009-12-16Merge with tipcallum
2009-12-11In LLPluginProcessParent, instead of killing the plugin process, terminate ↵Monroe Linden
it by closing the sockets. This lets it do some cleanup before exiting, instead of just getting shot.
2009-12-09DEV-43948 viewer2 is writing session data into the 'read-only' installation ↵Tofu Linden
tree (mostly media stuff) propagate the parent app's OSUserAppDir (i.e. ~/.secondlife/) all the way down to plugins, if they need persistant user data/settings (like the webkit plugin needs a place to put its cache).
2009-11-30doxygen: exclude licensing blurbsbea@american.lindenlab.com
2009-11-10Added PluginAttachDebuggerToPlugins debug setting.Monroe Linden
Added accessors to get platform-specific process ID from LLProcessLauncher. Added an optional "debug" argument to LLPluginClassMedia::init() and LLPluginProcessParent::init() (defaults to false). Mac only: made the state machine in LLPluginProcessParent::idle() open a new window in Terminal.app with a gdb session attached to the plugin process upon successful launch.
2009-10-26Potential fix for https://jira.lindenlab.com/jira/browse/DEV-41702callum
and https://jira.lindenlab.com/jira/browse/DEV-38579. Both relate to media not working properly and were likely caused by an uninitialized heartbeat timeout.
2009-10-08Log the plugin version string when a plugin is loaded.Monroe Linden
2009-10-05Fixes for a different class of plugin failures (where loading the plugin dll ↵Monroe Linden
fails) causing an error message loop: Made LLPluginProcessParent differentiate between failures launching/loading the plugin and failures after the plugin has been loaded. This allows us to handle launch failures differently, since retrying is unlikely to fix them. Added new media event MEDIA_EVENT_PLUGIN_FAILED_LAUNCH to indicate a launch failure. Added a case for the new event to LLViewerMediaImpl::handleMediaEvent() that sets the "failed init" flag to prevent retries.
2009-10-01svn merge -r 134922:134973 ↵Monroe Williams
svn+ssh://svn.lindenlab.com/svn/linden/branches/media-on-a-prim/moap-7 Merging branches/media-on-a-prim/moap-7 down to viewer-2.0.
2009-08-27svn merge -r 129841:129910 ↵Monroe Williams
svn+ssh://svn.lindenlab.com/svn/linden/branches/moss/pluginapi_05-merge@129910 svn merge -r 129913:131718 svn+ssh://svn.lindenlab.com/svn/linden/branches/pluginapi/pluginapi_05 Some branch shenannigans in the pluginapi_05 branch caused this to become a two-part merge.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-16 16:00:05 +0000