gtk_clipboard_wait_for_contents is evil.

From: Martin Sevior (msevior@physics.unimelb.edu.au)
Date: Thu Nov 21 2002 - 02:03:43 EST

  • Next message: Hubert Figuiere: "Re: gtk_clipboard_wait_for_contents is evil."

    HI everyone,
                In our current clipboard in unix we have a method

      XAP_UnixClipboard::_getDataFromServer((T_AllowGet tFrom, const char**
                                              formatList,
                                             void ** ppData,
                                             UT_uint32 * pLen,
                                               const char **pszFormatFound)

    Which contains a call to...

    gtk_clipboard_wait_for_contents (clipboard, atom);

    This function allows the gtk event loop to cycle which is really, really
    bad.

    The method _getDataFromServer is called on almost every key press
    because it attached to toolbar listener to see if there is data that can
    be pasted.

    Have calls to a method which cycle the main loop in an uncontrolled way
    during the processing of events called out of the main loop is just
    asking for trouble. Try this.

    Fire up abiword within gdb. Open an existing document which paragraph
    breaks and hold down the delete key. Eventually you hit an assert.

    **** (1) Assert ****
    **** (1) pR at
    ../../../../../abi-unstable/src/text/fmt/xp/fl_BlockLayout.cpp:1393 ****
    **** (1) Continue ? (y/n) [y] : n

    If you follow the stack trace up through the gtk-* loop propagation you
    eventually get to

     XAP_UnixClipboard::_getDataFromServer(XAP_UnixClipboard::_T_AllowGet,
    char const**, void**, unsigned*, char const**) (this=0x856ac48,
        tFrom=TAG_ClipboardOnly, formatList=0x840e4c0, ppData=0xbfffea60,
        pLen=0xbfffea5c, pszFormatFound=0xbfffea64)
        at
    ../../../../../abi-unstable/src/af/xap/unix/xap_UnixClipboard.cpp:254
    254 GtkSelectionData* selection =
    gtk_clipboard_wait_for_contents (clipboard, atom);

    So this function caused us to process a new event before the previous
    event had been finished.

    This is really bad and is the root cause of a number of the races we've
    had recently.

    So we have to find a way to not call this function or to block the
    processing of gtk events while we're waiting for an answer from this
    function.

    Dom was working on this a little while ago but I thought I'd tell
    everyone what the issue is. The good news is that once this is fixed abi
    will be stabler than ever since we've really been stressing it in an
    unkind way.

    Cheers

    Martin



    This archive was generated by hypermail 2.1.4 : Thu Nov 21 2002 - 02:08:51 EST