summaryrefslogtreecommitdiff
path: root/indra/llplugin/llpluginmessagepipe.cpp
AgeCommit message (Collapse)Author
2019-01-14SL-10291 Replace apr_mutex with standard C++11 functionalityandreykproductengine
2017-04-19Turn off message that is expected behavior and will fill up the logs/consoleCallum Prentice
2017-04-19Hopeful fix for MAINT-7220 Windows Error Message 'SLPlugin.exe has stopped ↵Callum Prentice
working ' appears.
2015-11-10remove execute permission from many files that should not have itOz Linden
2013-08-09second phase summer cleaningRichard Linden
replace llinfos, lldebugs, etc with new LL_INFOS(), LL_DEBUGS(), etc.
2013-03-29Update Mac and Windows breakpad builds to latestGraham Madarasz
2011-11-21Greatly reduced the number of memcpy operations done on the media plug-in ↵Leslie Linden
message output pipe by removing 's = s.substr()' type operations. The output string is now cleared via 's.clear()' when its entire contents have been pumped and the beginning of the data is stored as an index when necessary, rather than modifying the initial string. Reviewed by davep.
2010-08-13Change license from GPL to LGPL (version 2.1)Oz Linden
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-02-10CID-52Tofu Linden
Checker: FORWARD_NULL Function: LLPluginMessagePipe::pump(double) File: /indra/llplugin/llpluginmessagepipe.cpp
2009-11-30doxygen: exclude licensing blurbsbea@american.lindenlab.com
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.