Difference between revisions of "Documentation/DevGuide/ProUNO/Characteristics of the Interprocess Bridge"
m |
|||
(3 intermediate revisions by 3 users not shown) | |||
Line 6: | Line 6: | ||
|NextPage=Documentation/DevGuide/ProUNO/Opening a Connection | |NextPage=Documentation/DevGuide/ProUNO/Opening a Connection | ||
}} | }} | ||
− | + | {{Documentation/DevGuideLanguages|Documentation/DevGuide/ProUNO/{{SUBPAGENAME}}}} | |
{{DISPLAYTITLE:Characteristics of the Interprocess Bridge}} | {{DISPLAYTITLE:Characteristics of the Interprocess Bridge}} | ||
The whole bridge is ''threadsafe'' and allows multiple threads to execute remote calls. The dispatcher thread inside the bridge cannot block because it never executes calls. It instead passes the requests to worker threads. | The whole bridge is ''threadsafe'' and allows multiple threads to execute remote calls. The dispatcher thread inside the bridge cannot block because it never executes calls. It instead passes the requests to worker threads. | ||
Line 14: | Line 14: | ||
* An ''asynchronous'' (or <code>oneway</code>) call sends the request through the connection and immediately returns without waiting for a reply. It is currently specified at the IDL interface if a request is synchronous or asynchronous by using the [oneway] modifier. | * An ''asynchronous'' (or <code>oneway</code>) call sends the request through the connection and immediately returns without waiting for a reply. It is currently specified at the IDL interface if a request is synchronous or asynchronous by using the [oneway] modifier. | ||
− | {{ | + | |
+ | {{Warn|Although there are no general problems with the specification and the implementation of the UNO <tt>oneway</tt> feature, there are several API remote usage scenarios where <tt>oneway</tt> calls cause deadlocks in {{AOo}}. Therefore do not introduce new <tt>oneway</tt> methods with new {{AOo}} UNO APIs.}} | ||
+ | |||
For synchronous requests, ''thread identity'' is guaranteed. When process A calls process B, and process B calls process A, the same thread waiting in process A will take over the new request. This avoids deadlocks when the same mutex is locked again. For asynchronous requests, this is not possible because there is no thread waiting in process A. Such requests are executed in a new thread. The series of calls between two processes is guaranteed. If two asynchronous requests from process A are sent to process B, the second request waits until the first request is finished. | For synchronous requests, ''thread identity'' is guaranteed. When process A calls process B, and process B calls process A, the same thread waiting in process A will take over the new request. This avoids deadlocks when the same mutex is locked again. For asynchronous requests, this is not possible because there is no thread waiting in process A. Such requests are executed in a new thread. The series of calls between two processes is guaranteed. If two asynchronous requests from process A are sent to process B, the second request waits until the first request is finished. | ||
+ | |||
Although the remote bridge supports asynchronous calls, this feature is disabled by default. Every call is executed synchronously. The oneway flag of UNO interface methods is ignored. However, the bridge can be started in a mode that enables the oneway feature and thus executes calls flagged with the <code>[oneway]</code> modifier as asynchronous calls. To do this, the protocol part of the connection string on both sides of the remote bridge must be extended by <code>',Negotiate=0,ForceSynchronous=0'</code> . For example: | Although the remote bridge supports asynchronous calls, this feature is disabled by default. Every call is executed synchronously. The oneway flag of UNO interface methods is ignored. However, the bridge can be started in a mode that enables the oneway feature and thus executes calls flagged with the <code>[oneway]</code> modifier as asynchronous calls. To do this, the protocol part of the connection string on both sides of the remote bridge must be extended by <code>',Negotiate=0,ForceSynchronous=0'</code> . For example: | ||
Line 29: | Line 32: | ||
as UNO URL for connecting to it. | as UNO URL for connecting to it. | ||
− | {{ | + | |
+ | {{Warn|The asynchronous mode can cause deadlocks in {{AOo}}. It is recommended not to activate it if one side of the remote bridge is {{AOo}}.}} | ||
{{PDL1}} | {{PDL1}} | ||
[[Category:Documentation/Developer's Guide/Professional UNO]] | [[Category:Documentation/Developer's Guide/Professional UNO]] |
Latest revision as of 11:46, 23 December 2020
The whole bridge is threadsafe and allows multiple threads to execute remote calls. The dispatcher thread inside the bridge cannot block because it never executes calls. It instead passes the requests to worker threads.
- A synchronous call sends the request through the connection and lets the requesting thread wait for the reply. All calls that have a return value, an out parameter, or throw an exceptions other than a RuntimeException must be synchronous.
- An asynchronous (or
oneway
) call sends the request through the connection and immediately returns without waiting for a reply. It is currently specified at the IDL interface if a request is synchronous or asynchronous by using the [oneway] modifier.
For synchronous requests, thread identity is guaranteed. When process A calls process B, and process B calls process A, the same thread waiting in process A will take over the new request. This avoids deadlocks when the same mutex is locked again. For asynchronous requests, this is not possible because there is no thread waiting in process A. Such requests are executed in a new thread. The series of calls between two processes is guaranteed. If two asynchronous requests from process A are sent to process B, the second request waits until the first request is finished.
Although the remote bridge supports asynchronous calls, this feature is disabled by default. Every call is executed synchronously. The oneway flag of UNO interface methods is ignored. However, the bridge can be started in a mode that enables the oneway feature and thus executes calls flagged with the [oneway]
modifier as asynchronous calls. To do this, the protocol part of the connection string on both sides of the remote bridge must be extended by ',Negotiate=0,ForceSynchronous=0'
. For example:
soffice “-accept=socket,host=0,port=2002;urp,Negotiate=0,ForceSynchronous=0;”
for starting the office and
"uno:socket,host=localhost,port=2002;urp,Negotiate=0,ForceSynchronous=0;StarOffice.ServiceManager"
as UNO URL for connecting to it.
![]() |
The asynchronous mode can cause deadlocks in Apache OpenOffice. It is recommended not to activate it if one side of the remote bridge is Apache OpenOffice. |
Content on this page is licensed under the Public Documentation License (PDL). |