info/CWS dba34a : OPropertySetHelper::setDependentFastPropertyValue

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

info/CWS dba34a : OPropertySetHelper::setDependentFastPropertyValue

frank.schoenheit


          Type: info
         Title: OPropertySetHelper::setDependentFastPropertyValue
     Posted by: [hidden email]
      Affected: -
         TaskId: i113188
<http://www.openoffice.org/issues/show_bug.cgi?id=113188>
Effective from: CWS dba34a
           CWS:
<http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300/dba34a>
    CWS status: ready for QA


*Summary*
--------
+ ::cppu::OPropertySetHelper::setDependentFastPropertyValue

*Description*
-------------
OPropertySetHelper, one of the central base classes for implementing
X(Multi/Fast)PropertySet, applies the following logic when one or more
values are to be set
- convertFastPropertyValue is called, giving the implementation the
  chance to normalize the to-be-set property value
- possible veto listeners are called to veto the property change
- setFastPropertyValue_NoBroadcast is called, giving the implementation
  the chance to actually set the new value
- possible change listeners are called to be notified of the property
change

The first and the third step are invoked with the classes mutex
locked, the second and the forth without a mutex lock - which is fine
so far.

Unfortunately, this implies that if the implementation of
setFastPropertyValue_NoBroadcast needs to set another (dependent)
property value, it is somewhat lost: Invoking
setFastPropertyValue_NoBroadcast for this other property would miss
the notifications, and invoking setPropertyValue would (implicitly) do
all the notifications with a locked mutex, which sooner or later will
lead to a deadlock.

So, setDependentFastPropertyValue has been introduced at the
OPropertySetHelper. It is intended to be called from within
setFastPropertyValue_NoBroadcast, and it will carry out the first and
the third step from above, actually converting and setting the new
property value, but it will save the property change notification for
the point in time where the first setFastPropertyValue_NoBroadcast
returns, and thus the own mutex can be released.

Multiple calls to setDependentFastPropertyValue can be made, the
resulting change notifications are collected.

Note that it is not feasible to use this for constrained properties -
this would required notifying veto listeners from within
setDependentFastPropertyValue, which is deadlock-prone, again, since
the method by definition needs to be called with the mutex locked.


Send feedback to [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]