Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Death of a (Sw-)Client

Death of a (Sw-)Client

This talk covers one of the oldest pieces of LibreOffice Writer infrastructure: The SwClient/SwModify classes and their poor attempt at providing a observer pattern in Writer code. The talk will first discuss the existing implementation, its limitations, pitfalls and common abuse beyond its original purpose. This should both help developers avoiding common misshaps with its usage where unavoidable, motivate the use of alternatives and finally the incremental removal of SwClient and SwModify wherever possible. The talk will continue to present efforts and progress on incremental removal so far and what is still left to do. Finally, some thoughts will be shared on what further developments might be unblocked once SwClient/SwModify removal is finished.

Bjoern Michaelsen

September 26, 2018

More Decks by Bjoern Michaelsen

Other Decks in Programming


  1. Death of a (Sw)Client
    Bjoern Michaelsen, Twitter: @Sweet5hark
    2018-09-27, LibreOffice Conference, Tirana

    View Slide

  2. Death of a (Sw)Client
    Part One: What is SwClient?

    View Slide

  3. Observer pattern
    The Observer pattern addresses the following problems:
    – A one-to-many dependency between objects should be defined without making the objects tightly coupled.
    – It should be ensured that when one object changes state an open-ended number of dependent objects are updated
    – It should be possible that one object can notify an open-ended number of other objects.
    The responsibility of observers is to register (and unregister) themselves on a subject (to get notified of
    state changes) and to update their state (synchronize their state with subject's state) when they are
    This makes subject and observers loosely coupled. Subject and observers have no explicit knowledge of
    each other.
    (source: Wikipedia CC-BY-SA/GFDL)

    View Slide

  4. LibreOffice observer patterns





    and: SwClient/SwModify

    View Slide

  5. SwModify::CallSwClientModify
    SfxPoolItem* pOld
    SfxPoolItem* pNew

    View Slide

  6. SwModify and SwClient

    A SwModify (Observable) notifies its SwClients (Listeners)
    about events

    The SwClients are collected in an intrinsic doubly linked list

    So: When an event happens at the SwModify it iterates over
    its SwClients and dumps this event in the handler function

    View Slide

  7. Modification while iterating

    "a FOO client added as listener to a BAR during client

    SwModifies (Observables) keep a list of live iterators

    View Slide

  8. In Writer ~everything is a SwClient

    The usual way to use SwClient/SwModify is to derive from
    one of them

    Even SwModify is derived from SwClient

    When you want to send or receive events you need to
    derive from SwClient

    View Slide

  9. std::unique_ptr SwClient::CheckRegistration( const SfxPoolItem* pOld )
    // this method only handles notification about dying SwModify objects
    if( !pOld || pOld->Which() != RES_OBJECTDYING )
    return nullptr;
    const SwPtrMsgPoolItem* pDead = static_cast(pOld);
    if(!pDead || pDead->pObject != m_pRegisteredIn)
    // we should only care received death notes from objects we are following
    return nullptr;
    // I've got a notification from the object I know
    SwModify* pAbove = m_pRegisteredIn->GetRegisteredIn();
    // if the dying object itself was listening at an SwModify, I take over
    // adding myself to pAbove will automatically remove me from my current pRegisteredIn
    // destroy connection
    return std::unique_ptr(new sw::ModifyChangedHint(pAbove));

    View Slide

  10. Reregistering horrors

    When a SwModify (Observable) dies …

    … by default all SwClients (Listeners) reregister at the
    pAbove of the SwModify

    View Slide

  11. Multithreading, Locking & Mutexes

    Writer is a big mudball of SwClients throwing events at
    each other all over the place

    Sometimes even in circles: Looping Louie

    No hierarchy, no locality

    View Slide

  12. Whats this?

    View Slide

  13. GetRegisteredIn() is a void*

    There is no static guarantee about the type
    GetRegisteredIn() returns

    git grep GetRegisteredIn|grep static_cast|wc -l

    View Slide

  14. Manual iteration of SwClients

    SwModifies (and even third party classes) often iterate
    over SwClients directly

    Even iterating over a subset of SwClients (based on type)
    is done regularly
    – Renders the Observer pattern pointless as the Observable
    (SwModify) has to have deep knowledge about clients
    – Also: a good cache smashing excerise and general
    performance horror

    View Slide

  15. Random calls into event handlers

    NotifyClients: git grep NotifyClients|grep -v calbck|wc -l

    ModifyNotification: git grep ModifyNotification\(|grep -v
    calbck|wc -l

    View Slide

  16. Lapsed Listener Problem:
    A “feature”?

    Unfortunately, throwing naked pointers all over Writer is fragile

    However, the default implementation cover it reasonably well …

    … so the “wise” Writer devs of old used it for memory

    View Slide

  17. SwDepend: A broken workaround
    for brokeness

    How to listen to more than one Observable (SwModify)

    – Have a minimal SwClient implementation as a proxy helper
    – Forward its events to the “real” SwClient (also expect to be
    friended by that class)

    View Slide

  18. Death of a (Sw)Client
    Part Two: The long death of SwClient

    View Slide

  19. Add unittests!

    Yes, it was the ~most fundamental implementation in

    Nope, there hadnt been any unittests

    View Slide

  20. Remove Cargo Cult/Dead Code

    Remove dead/unused/cargo cult code

    Cut back to a core that does the observer pattern and only

    View Slide

  21. SfxHints and LegacyHints

    Add sw::LegacyHints which is a SfxHint ...

    … and also wraps the old event messages.

    So the events are already in the new “format” and are
    tunneled through the old implementation.

    View Slide

  22. SwModify::CallSwClientModify
    SfxPoolItem* pOld
    SfxPoolItem* pNew

    View Slide

  23. SwModify::CallSwClientModify
    SfxPoolItem* pOld
    SfxPoolItem* pNew

    View Slide

  24. SvtBroadcaster::Broadcast
    SfxPoolItem* pOld
    SfxPoolItem* pNew

    View Slide

  25. Some internal renovation

    Use saner STL/boost container
    – boost/ring.hxx

    Make SwClientIterator somewhat more typesafe
    – template< typename TSource >
    class SwIterator final
    – add some static_asserts on TSource

    View Slide

  26. Add sw::BroadcasterMixin

    Mixin-class that adds a good old SfxBroadcaster as a member
    to objects

    Still easy use by inheritance, but otherwise its composition
    over inheritance

    This allow incremental migration, and breaks the
    “everything must derive from SwClient”
    down to a
    “everything can derive from a sw::BroadcasterMixin”

    View Slide

  27. Remove SwDepend

    SfxListener can listen to multiple observables (SfxBroadcasters),
    so no more need for SwDepend

    Incremental migration, so we might need both
    – SfxBroadcaster/SfxListener
    – SwModify/SwClient
    for some time

    View Slide

  28. Progress (What happened so far)

    git grep public.*SwClient sw/source/core/unocore/|wc -l

    git grep SwClient sw/source/core/access/|wc -l
    4 (plus 2 in comments)

    git grep SwClient sw/source/core/layout/|wc -l

    View Slide

  29. Regressions :/

    Reported, triaged, bibisected and fixed:
    – tdf#117749
    – tdf#117774

    Reported, triaged, bibisected and not fixed on master:
    – tdf#118049
    – tdf#118725
    – tdf#118833

    Reported, triaged, bibisected and not fixed on 6.1:
    – tdf#120115

    View Slide

  30. Death of a (Sw)Client
    Bjoern Michaelsen, Twitter: @Sweet5hark
    2018-09-27, LibreOffice Conference, Tirana

    View Slide