|
||||||||||||||
|
|
|||||||||||||
|
|
|||
|
|||
|
|||
|
Threads and WebRenderer | ||
|
|
|
|
|
|
The majority of WebRenderer
is thread-safe, meaing that the majority of WebRenderer methods
can be called from any thread.
The following events are fired in the WebRenderer thread: BrowserListener.onLoadIntercept NetworkListener.onHTTPInterceptHeaders PromptListener.onPromptDialog It is a good idea to thread any calls to WebRenderer methods that have return values if calling WebRenderer methods within the above events. Thread Example: Thread thread = new Thread(new Runnable() { public void run() { // Call to WebRenderer methods with return values } }); thread.start(); Most return value methods are safe to call, but some could cause deadlock if the return causes another blocking event to be fired. For example if the IBrowserCanvas.executeScriptWithReturn function runs JavaScript code that launches an alert dialog, PromptListener.onPromptDialog would fire. However if the executeScriptWithReturn was run from within one of the blocking events, deadlock would be caused. Note: Non-WebRenderer method calls do not need to be threaded if called within the methods listed above. Methods fired in new Threads The ProtocolListener.onOpen event is fired in a new thread each time. This means you may have multiple calls to this running at the same time, and you must sychronize any shared data that is accessed. The thread created is destroyed after the firing of the onOpen method and the ProtocolEvent object is the reference for the protocol data (see custom protocols). All other events are fired on the AWT-EventQ thread (also known as the Swing Thread). |
|
|
|
|
|
|
|
|
|
|
|
Copyright � JadeLiquid Software - www.jadeliquid.com |