Architectural changes to LLPlugin message processing.

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().

0 files changed, 0 insertions, 0 deletions