incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karsten Burger" <>
Subject Re: Mixed oneway and normal/synchronous UNO interface calls
Date Fri, 17 Aug 2012 08:13:50 GMT

-------- Original-Nachricht --------
> Datum: Thu, 16 Aug 2012 17:30:04 +0200
> Von: "Jürgen Schmidt" <>
> An:
> Betreff: Re: Mixed oneway and normal/synchronous UNO interface calls

> On 8/16/12 4:49 PM, Andre Fischer wrote:
> > On 16.08.2012 15:19, Karsten Burger wrote:
> >> Hello,
> >>
> >> I posted this to ooo-users but was advised to post it here:
> >>
> >> I found this guarantee for oneway calls:
> >>
> >>
> >>
> >>>>     sequence of calls:
> >>>>     UNO allows declaring a method oneway (or asynchron). Multiple,
> >>>>     oneway calls are guaranteed to be executed in the same sequence
> as
> >>>>     they were called.
> >>
> >>
> >> Now my question: what happens when oneway and normal synchronous calls
> >> are mixed?
> >>
> >> We use UNO as a component framework for our large project (on Redhat
> >> Linux EL5.8)  with many of our own interfaces. E.g. if several oneway
> >> calls are issued, and then a synchronous call, does the synchronous
> >> call wait until the oneway calls are finished? Or are normal and
> >> oneway/async calls not connected?
> >>
> >> I also found this:
> >>
> >>
> > 
> > I am afraid that I can not answer your question but I am glad that you
> > found this URL.  It may describe the reason for a freeze bug that came
> > up recently (
> > 
> > -Andre
> I can't remember all the details around oneway calls but I think we did
> not really deprecated them but gave advice to not use oneway calls.
> I think you have to do some tests for your scenario to ensure that the
> behaviour is exactly what you expected or need.
> What kind of project you are working on, it sounds interesting that you
> are using UNO as component framework.
> I remember a company who decided to use UNO for their project as well
> and they had chosen UNO because of the feature set and performance
> compared to other middleware technologies. Several years ago and they
> did a very good analysis before they had contacted us and asked if we
> could extract UNO from the office make it standalone available. That was
> the birth of the URE.
> But my plan is more to rework the 3 layer office to get rid of some
> complexity. We don't release an URE at Apache at the moment.
> Juergen

Hello Juergen,

thanks for your reply. Indeed it is the same company that I am currently working for. As far
as I remember, they chose UNO because of
- the minimal overhead when calling into a service when it is in the same process (a virtual
method call)
- the ability to cope with a large number of interfaces and services, also regarding compile

They made it the backbone of the newer, component-based parts of the software, and they use
oneway calls a lot: in this way they can reduce the IPC traffic between clients and a server

Regards, Karsten

P.S. regarding deadlocks:

Using remote UNO oneway calls can cause deadlocks.

This is because UNO maintains the sequence of calls (both synchronous and oneway) made by
a caller on a per caller thread basis.

Note: oneway != asynchronous. Asynchronous calls would not maintain the call sequence.

The problem may show-up whenever a oneway call triggering a callback is followed by a synchronous
call issued in the same thread.

See here for the full explanation.

The problem can be avoided by choosing one option of:

    * On the caller side: Issue all oneway calls in a separate thread.
    * On the callee side: Immediately dispatch each oneway call to a separate thread and return.

Dr. Karsten Burger 
Lindenstraße 23
72074 Tübingen

Telefon 0171 124 134 8

View raw message